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The S/KEY One-Time Password System 

Status of this Memo 

This memo provides lnformation_for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 



Abstract 



This document describes the S/KEY* Ono-Tlme Password system as 
released for public use by Bellcore and as described in reference 
[3] . A reference Impleme-^tation and documentation are available by 
anonymous ftp from ftp.belicore.com in the directories pub/nmh/... 

Overview 



One form of attack on computing system connected to the Internet is 
eavesdropping on network connections to obtain login Id^s and 
passwords of legitimate users. The captured login id and password 
are, at a later time, used gain access to the system. The S/KEY 
One-Time Password system is designed to counter this type of attack, 
called a replay attack. 

With the S/KEY system, only a single use password ever crosses the 
network. The user's secret pass-phrase never crosses the network at 
any time, including during login or when. executing other commands 
requiring authentication such as the UNIX commands passwd or su. 
Thus, it is not vulnerable to eavesdropping/ replay attacks. Added ^. 
security is provided by the property that no secret information need 
be stored on any system, including the host being protected. 

The S/KEY system protects against external passive attacks against 
tho authentication subsystem. It does not prevent a network 
®»'^osdropper from gaining access to private information, and does not 
"iv provide protection against "inside jobs" or against active attacks 

y^X . where the potential intruder as able to intercept and modify the 

packet stream. 
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Introduction 



There are two sides to the operation of the S/KEY one-time passwrd 
system. On the client side, the appropriate one-time password must 
be generated. On the host side, the server must verify the one-time 
password and permit the secure changing of the user's secret pass- 
phrase. 
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An S/KCY system client passes the user's secret pass-phrase through 
multiple applications of a secure hash function to produce a one-time 
pass%#ord. On each use, the number of applications is reduced by one. 
Thus a unique sequence of passwords Is generated. The S/KEY system 
host verifies the one-time password by making one pass though the 
secure hash function and comparing the result with the previous one- 
time password. This technique was first suggested by Leslie Lamport 
[IJ. 

Secure Hash Function 

A secure hash function is a function that is easy to compute in the 
forward direction, but computationally infeaslble to invert. The 
S/KEY system is based on the MD4 Message Digest algorithm designed by 
Ronald Rivest [2] . Since the S/KEY authentication system went into 
use, the M05 Message Digest was released. We have chosen to continue 
to use MD4 due the large number of client programs that have been 
distributed. Some sites have generated functionally similar systems 
based on MD5. Clearly clients and hosts must use the same secure 
hash function to Interoperate*. ~ 

The S/KEY system one-time passwords are 64 bits in length. This is 
believed to be long enough to be secure and short enough to be 
manually entered (see below. Form of Passwords) when necessary. 

The S/KEY system applies the secure hash function multiple times, 
producing a 64 bit final output. MD4 accepts an arbitrary number of 
bits as input and produces a 128 bit output. The S/KEY secure hash 
function consists of applying MD4 to a 64 bit input and folding the 
output of MD4 with exclusive or to produce a 64 bit output. 

Generation of One-Time Passwords 

This section describes the computation of the S/KEY one-time 
passwords. It consists- of a preparatory step in which all inputs are 
combined, a generation step where the secure hash function is applied 
multiple times, and an output function where the 64 bit one-time 
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password Is displayed in readable form. 

The client's secret pass phrase may be of any length and should be 
more than eight characters. As the S/KEY secure hash function 
described above accepts a 64 bit input, a preparatory step is needed. 
In this step, the pass phrase is concatenated with a seed that is 
transmitted from the server in clear text. This non-secret seed 
allows a client to use the same secret pass phrase on multiple 
machines (using different seeds) and to safely recycle secret 
passwords by changing the seed. (For ease in parsing, the seed may 
^ not contain any blanlcs, and should consist of strictly alphanumeric 
characters.) The result of the concatenation is passed through MD4, 
and then reduced to 64 bits by excluslve-OR of the two S-byte halves. 

The following code fragment uses the MD4 implementation defined in 
RFC 1320 (2] and defines the preparatory step: 

strcpy(buf ,seed) ; 
strcat (buf ,passwd) ; 
MDbegin((md) 

HDupdate(£md, (unsigned char ^ )buf , 8*buf len) ; 

/♦ Fold result to 64 bits */ 
rod.bufferCO) md, buffer (2] ; 
md.bufferCD ^» md.buf fer (3] ; 
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A sequence of one-time passwords Is produced by applying the secure 
hash function multiple times to the output of the preparatory step 
(called S). That is, the first one-time password is produced by 
passing S through the secure hash function a number of times (N| 
specified by the user. The next one-time password is generated by* 
passing S though the secure hash function N-1 times. An eavesdropper 
who has monitored the transmission of a one-time password would not 
be able to generate any succeeding password because doing so would 
require inverting the hash function. 

Form of Passwords 

The one-time password generated by the above procedure is 64 bits in 
length. Entering a 64 bit number is a difficult and error prone 
process. Some S/KGY system one-time password calculator programs 
insert this password Into the input stream^ others make it available 
for system cut and paste. Some arrangements require the one-time 
password to be entered manually. The S/KEY system Is designed to 
facilitate this manual entry without impeding automatic methods. The 
one-time password is therefore" converted to, and accepted as, a 
sequence of six short (1 to 4 letter) English words. Each word is 
chosen from a dictionary of 2048 words; at 11 bits per word, all 
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one-time passwords may be encoded. Interoperability requires at all 
S/KEY system hosts and calculators use the same dictionary. The 
standard dictionary is attached to this RFC. 

Verification of One-Time Passwords 

A function on the host system that requires S/KEY authentication is 
expected to issue an S/KEY challenge. This challenge give the client 
the current S/KEY parameters - the sequence number and seed. It Is 
Important that the S/KEY challenge be in a standard format so that 
automated clients (see below) can recognize the challenge and extract 
the parameters. The format of the challenge is: 

s/key sequence_integer seed 

The three tokens are separated by single space characters. The 
challenge is terminated by a blank or a newline. 

Given the parameters and the secret pass phrase, the client can 
compute (or lookup) the one time password. It then passes it to the 
host system where It can bo verified. 

The host system has a file (on the UNIX reference Implementation it 
is /etc/skeykeys) containing, for each user, the one-time password 
from the last successful login, or it may be initialized with the 
first one-time password of the sequence using the keyinit command 
(this command name may be implementation dependent). To verify an 
authentication attempt, it passes the transmitted one-time password . 
through the secure hash function one time, if the result ^f this 
operation matches the stored previous one-time password, tlie 
authentication is successful and the accepted one-time :password is 
stored for future use. 

Because the number of hash function applications executed* by the 
client decreases by one each time, at some point the user must 
reinitialize the system of be unable to login again. This is done by 
using the keyinit command which allows the changing of the secret 
pass phrase, the iteration count, and the seed. A frequent technique 
is to increment a trailing digit (s) of the seed and to reset the 
iteration count (to something in range of 500-1000) . 

Clients 

Several programs are available to calculate S/KEY one time passwords. 
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Included In the reference implementation are command line Interfaces 
for UNIX and PC systems (key), TSR interfaces for PCs (ctkey, 
termkey, and popkey) , and GUI interfaces for Macintosh and Windows 
(keyapp and un-named Macintosh Interface) . 



The roost basic calculator is the key conunand whose format Is: 

key (*n count] sequence seed 

The optional count Is used to. dlsplay more than a single one time 
password. This is useful ,.t6 create a paper list of one time 
passwords. 

The most automated calculator Is the termkey program that runs as a 
Terminate and Stay Resident (TSR) program on a PC. It scans the 
screen to find the S/KEY parameters^ prompts for the secret pass 
phrase, and stuffs the one time password into the keyboard buffer. 
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Dictionary for Converting Between S/KEY 6-Word and Binary Formats 

This dictionary is from the module put.c. The code for this module, 
and an implementation of the entire S/KEY One Time Password System is 
available by anonymous ftp from ftp.bellcore.com in the directory 
pub/nmh/skey. 



1 


"A", 


"ABE-, 


•ACE", 


•ACT", 


"AD", 


"ADA", 


"ADD", 


"AGO", 


"AID", 


"AIM", 


"AIR", 


"ALL", 


"ALP", 


"AM", 


-AMY", 


"AN", 


"ANA", 


•AND", 


"ANN", 


"ANT", 


"ANY", 


"APE", 


"APS", 


•APT", 


"ARC", 


•ARE", 


"ARK", 


"ARM", 


-ART", 


"AS", 


"ASH", 


"ASK", 


"AT", 


"ATE", 


"AUG", 


"AUK", 


"AVE", 


"AWE", 


"AWK", 


"AWL", 


"AVW, 


"AX", 


-AYE", 


"BAD", 


"BAG-, 


"BAH", 


"BAM", 


"BAN", 


•BAR", 


"BAT", 


•BAY", 


"BE", 


"BED", 


"BEE", 


"BEG", 
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"BEN", 


"BET", 


"BEY", 


"BIB", 


"BOB", 


"BOG", 


"BON", 


"BOO", 


-BUD", 


"BUG", 


"BUM", 


"BUN", 


"BYE", 


"CAB", 


"CAL", 


"CAM", 


"CAW", 


"COD", 


"COG", 


"COL", 


"COW", 


"COY", 


"CRY", 


"CUB", 


"DAB", 


"DAD", 


"DAM", 


"DAN", 


"DEN", 


"DES", 


"DEW", 


"DID", 


"DO",'" 


"DOE", 


"DOG", 


"DON", 


"DUD", 


"DUE", 


"DUG", 


"DUN", 


"EGG", 


"EGO", 


"ELI", 


"ELK", 


"EST", 


"ETC", 


"EVA", 


"EVE", 


"FAR", 


"FAT", 


"FAY", 


"FED", 


"FIN", 


"FIR", 


"FIT", 


"FLO", 


"FRY", 


"FUM", 


"EVN", 


"FUR", 


"GAM", 


"GAP", 


"GAS", 


"GAY", 


"GIG", 


"GIL", 


"GIN", 


"GO", 


"GUT", 


"GUY", 


"GYM", 


"GYP", 


"HAN", 


"HAP", 


"HAS", 


"HAT", 


"HEN", 


"HER", 


"HEW", 


"HEY*'> 


"HIS", 


"HIT", 


"HO", 


"HOB", 


"HOT", 


"HOW", 


"HUB", 


"HUE", 


"I", 


"ICY", 


"IDA", 


"IF", 


"lO", 


"ION", 


"IQ", 


"IRA", 


"ITS", 


"IVY", 


"JAB", 


"JAG", 


"JAY", 


"JET", 


"JIG", 


"JIM", 


"JOT", 


"JOY", 


"JUG", 


"JUT", 


"KID", 


":aM", 


"KIN", 


"K7T", 


"LAG", 


"LAM", 


"LAP", 


"LAW", 


"LEG", 


"LEN", 


"LEO", 


"LET", 


"LIP", 


"LIT", 


"LO", 


"LOB", 


"LOU", 


"LOW", 


"LOY", 


"LUG", 


"MAE", 


"MAN", 


"MAO", 


"MAP", 
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"MEG", 


"MEL", 


"MEN", 


"MET", 


"MOB", 


"MOD", 


"MOE", 


"MOO", 


"MUD", 


-MUG", 


"MUM", 


•MY", 


"NAT", 


"NAY", 


"NE", 


"NED", 


"NIL", 


"NIP", 


"NIT", 


"NO", 


"NOT", 


"NOV", 


"NOW", 


"NU", 


"QAK"^, 


"OAR", 


"OAT", 


"ODD", 


"OH", 


"OIL", 


"OK", 


"OLD", 


"ORE", 


"ORR", 


"OS", 


"OTT", 


"OWE", 


"OWL", 


"OWN", 


-OX", 


"PAN", 


•PAP", 


"PAR", 


"PAT", 


"PEN", 


"PEP", 


"PER", 


-PET-, 


"PIN", 


"PIT", 


"PLY", 


-P0-, 


"POW, 


"PRO", 


-PRY", 


-PUB", 


"QUO", 


"RAG", 


"RAM", 


-RAN-, 


"REB", 


"RED", 


"REP", 


"RET", 


"RIO", 


"RIP", • 


"ROB", 


"ROD", 


"ROY", 


"RUB", 


"RUE", 


"RUG", 


"SAD", 


"SAG", 


"SAL", 


"SAM", 


"SAY", 


"SEA", 


"SEC", 


■SEE^, 


"SHY", 


"SIN", 


"SIP", 


-SIR", 


"SLY", 


"SO", 


"SOB", 


"SOD", 


"SPA", 


"SPY", 


rsuB", 


"SUD", 


"TAB", 


"TAD", 


"TAG", 


•TAN", 


"TEE", 


"TEN", 


"THE", 


•THY", 


"TIP", 


"TO", 


"TOE", 


"TOG", 


"TOW", 


"TOY", 


"TRY", 


"TUB", 


•UN", 


-UP", 


"US^, 


•USE-, 


•WAD", 


-WAG", 


•WAR", 


"WAS^, 


•WEE", 


-WET", 


"WHO", 


•WHY", 


"WOO^, 


"WOW", 


"WRY", 


-WU-, 


"YEA", 


"YES", 


"YET", 


•YOU", 


■ABUT", 


"ACHE", 


"ACID", 


"ACME", 


"ADDS", 


"ADEN", 


"AFAR", 


"AFRO", 


"AIDE", 


"AIDS", 


"AIRY", 


"AJAR" , 



"BID", 


"BIG", 


"BIN", 


"BIT" 


"BOP", 


"BOW", 


"BOY", 


"BUB" 


"BUS", 


"BUT", 


"BUY", 


"BY", 


"CAN", 


"CAP", 


"CAR", 


"CAT" 


"CON", 


"COO", 


"COP", 


"COT" 


"CUE", 


"CUP", 


"CUR", 


■CUT* 


"DAR", 


"DAY", 


"DEE", 


■DEL" 


"DIE", 


■DIG", 


"DIN", 


"DIP" 


"DOT", 


•DOW", 


"DRY", 


"DUB" 


"EAR", 


"EAT", 


"ED"^ 


-EEL" 


"ELM", 


"ELY", 


"EM", 


"END" 


"EWE", 


"EYE", 


"FAD", 


"FAN" 


"FEE", 


•FEW", 


"FIB", 


"FIG" 


"FLY", 


•FOE^, 


"FOG", 


-FOR" 


"GAB", 


•GAD", 


"GAG", 


•GAL" 


"GEE", 


■GEL", 


"GEM", 


•GET^ 


"GOT", 


■GUM", 


"GUN", 


"GUS" 


"HA", 


"HAD", 


"HAL", 


"HAM" 


"HAW", 


"HAY", 


"HE", 


"HEM" 


"HI", 


■HID", 


"HIM", 


"HIP" 


"HOC", 


■HOE", 


"HOG", 


"HOP" 


"HUG", 


"HUH", 


"HUM", 


"HUT" 


"IKE", 


"ILL", 


"INK", 


"INN" 


"IRE", 


"IRK", 


"IS", 


"IT", 


"JAM", 


"JAN^, 


"JAR", 


"JAH" 


"JO", 


•JOB^, 


"JOE", 


"JOG" 


rKAY", 


"KEG", 


"KEN", 


"KEY" 


"LA", 


"LAB", 


"U^C", 


"LAD" 


"LAY", 


"LEA", 


"LED", 


"LEE" 


"LEW", 


•LID^, 


"LIE", 


"LIN" 


"LOG", 


"LOP", 


"LOS", 


"LOT" 


"LYE", 


"MA", 


"MAC", 


-MAD- 


"MAT", 


"MAW", 


"MAY", 


-ME", 
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-MEW", 


"MID", 


"MIN", 


"MIT", 


"MOP", 


"MOS", 


"MOT", 


"MOW", 


"NAB", 


"NAG", 


"NA»4", 


"NAP", 


"NEE", 


•NET", 


"NEW", 


"NIB", 


"NOB", 


"NOD", 


"NON", 


"NOR", 


•NUN", 


"NUT", 


"O", 


"OAF", 


"ODE", 


■OF", 


"OFF",' 


"OFT", 


"ON", 


■ONE", 


"ORr, 


"ORB", 


"OUR", 


■OUT", 


"OVA", 


"OW", 


"PA", 


"PAD", 


•PAL", 


"PAM", 


"PAW", 


"PAY", 


"PEA", 


"PEG", 


•PEW", 


"PHI", 


"PI", 


"PIE", 


•POD", 


"POE", 


"POP", 


"PCT", 


"PUG", 


"PUNr, 


"PUP", 


"PUT", 


"RAP", 


"RAT", 


"RASi-, 


"RAY", 


"RIB", 


"RID", 


-RIG", 


"RIM", 


"ROE", 


"RON", 


"ROT", 


"ROW", 


•^RUM", 


"RUN", 


"RYE", 


"SAC", 


"SAN", 


"SAP**, 


"SAT", 


■SAW", 


"SEN", 


"SET", 


"SEW", 


"SHE", 


"SIS", 


"SIT", 


"SKI", 


"SKY", 


"SON", 


"SOP", 


"SOW", 


"SOY", 


"SUE", 


"SUM", 


"SUN", 


"SUP", 


"TAP", 


"TAR", 


"TEA-, 


"TED", 


"TIC", 


"TIE", 


"TIM", 


-TIN-, 


"TOM", 


"TON", 


"TOO", 


"TOP", 


"TUG", 


"TUM", 


"TUN", 


"TWO", 


-VAN", 


•VAT^, 


"VET", 


"VIE", 


"WAY", 


•WE", 


"WEB", 


"WED", 


•wiw. 


•WIT", 


"WOK", 


"WON", 


"YAM", 


•YAP^, 


•YAW-, 


"YE", 


"ABED", 


•ABEL", 


•ABET^, 


"ABLE", 


"ACRE", 


•ACTA", 


"ACTS", 


-ADAM", 


"AGEE", 


"AHEM", 


"AHOY", 


-AIDA-, 


"AKIN", 


"ALAN", 


"ALEC", 


•ALGA^, 



httpy/www.ictf.org/rfc/rfcl760.txt 



9/16/99 



rfcl760.txt at www.ictf.org 



PagcToflO 



"ALIA", 


"ALLY", 


"AliW", 


"ALOE" , 


"ALSO", 


"ALTO", 


"ALUM", 


"ALVA* , 


"AMEN", 


"AMES", 


"AMID", 


"AMMO", 


•AMOK", 


"AMOS", 


•AMRA", 


"ANDY", 


"ANEW", 


"ANNA", 


"ANNE" , 


"ANTE" , 


"ANTI", 


"AQUA", 


"ARAB", 


"ARCH", 


"AREA", 


"ARGO", 


"ARID", 


•ARMY", 


•ARTS", 


"ARTY", 


•ASIA", 


"ASKS", 


"ATOM", 


"AUNT", 


•AURA", 


"AUTO", 


"AVER" , 


"AVID", 


"AVIS", 


-AVON", 


"AVOW", 


"AWAY", 


■AWRY", 


"BABE", 


"BABY", 


"BACH", 


"BACK", 


"BADE", 


"BAIL", 


"BAIT", 


"BAKE", 


-BALD", 


-BALE", 


-BALI-, 


"BALK", 


"BALL-, 


"BALM", 


"BAND-, 


"BANE", 


"BANG", 


"BANK", 


"BARB", 


"BARD", 


■BARE", 


"BARK", 


"BARN", 


"BARR", 


"BASE", 


"BASH", 


"BASK", 


"BASS", 


•BATE", 


"BATH", 


"BAWD", 


"BAWL", 


"BEAD", 


"BEAK", 


"BEAM", 


"BEAN", 


•BEAR", 


"BEAT", 


"BEAU", 


"BECK", 


"BEEF", 


"BEEN", 


"BEER", 


"BEET", 


•BELA-, 


"BELL", 


"BELT", 


"BEND", 


"BENT", 


"BERG", 


"BERN", 


"BERT", 


"BESS", 


"BEST", 


"BETA", 


"BETH", 


•BHOY", 


"BIAS", 


"BIDE", 


"BIEN", 


"BILE", 



Haller 



(Page 8] 



RFC 1760 



The S/ KEY ..One-Time Password System 



February 1995 



ft- 



"BILK", 
"BLAT", 
"BLUM", 
"BOGY", 
"BOND-, 
"BOOT", 
"BOWL", 
"BREW", 
"BULK", 
"BURR", 
■CADY", 
•CAME", 
"CASE*, 
•CERN", 
"CHIC", 
"CITY", 
"CLOT", 
"CODA", 
"COLD", 
"COOT", 
"CRAB", 
"CUBA", 
•CURE", 
•DANE", 
"DATA", 
"DEAL", 
"DEFT", 
•DIED", 
•DISC^, 
•DOLT", 
■DOUG", 
■DREW^, 
"DUET^, 
"DUTY", 
•ECHO", 
"ELAN", 
•ERIC^, 
"E7VDE", 
•FARM", 
•FEET", 
•FIGS", 
•FIRM", 
•FLAM", 
"FLOG", 
"FOLD", 
•FORE", 
"FRAU", 
"FUEL", 



"BILL", 
"BLED", 
"BLUR", 
•BOHR", 
"BONE", 
•BORE", 
"BOYD", 
"BRIG", 
"BULL", 
"BURT", 
"CAFE", 
"CANE", 
"CASH", 
"CHAD", 
"CHIN", 
"CLAD", 
"CLUB", 
"CODE", 
"COLT", 
"CORD", 
"CRAG", 
"CUBE", 
"CURL", 
"DANG", 
"DATE", 
"DEAN", 
•DEFY", 
"DIET", 
"DISH", 
■DOME", 
■DOUR", 
■DRUB^, 
•DUKE^, 
•EACH", 
"EDDY", 
"ELBA", 
•EROS", 
"FAIL", 
"FAST", 
"FELL", 
•FILE", 
■nSH", 
"FLAT", 
"FLOW", 
"FOLK", 
"FORK", 
"FRAY", 
"FULL", 



"BIND" 
"BLEW" 
"BOAR" 
"BOIL" 
"BONG" 
"BORG" 
"BRAD" 
"BRIM" 
"BUNK" 
"BURY" 
"CAGE" 
"CANT" 
"CASK" 
"CHAR" 
"CHOU" 
"CLAM" 
"CLUE" 
•CODY" 
"COMA" 
"CORE" 
"CRAM" 
"CUFF" 
"CURT" 
"DANK" 
"DAVE" 
"DEAR" 
"DELL" 
"DIME" 
■DISK" 
•DONE" 
"DOVE^ 
•DRUG" 
"DULL" 
"EARL" 
"EDEN", 
"ELLA^, 
•EVEN", 
"FAIN* 
•FATE" 
"FELT* 
•FILL* 
"FISK- 
"FLAW" 
•FLUB" 
"FOND" 
"FORM" 
"FRED" 
"FUME", 



"BING", 
"BLOB", 
"BOAT", 
"BOLD", 
"BONN", 
"BORN", 
"BRAE", 
"BROW", 
"BUNT", 
"BUSH*, 
"CAIN", 
"CARD", 
"CAST", 
"CHAT", 
"CHOW", 
"CLAN", 
"COAL", 
"COED", 
"CCMB", 
"CORK**, 
"CRAY", 
•CULL", 
"CUTS", 
"DARE", 
•DAVY", 
"DEBT", 
"DENT", 
"DINE", 
■DIVE", 
■DOCM^, 
"DOWN", 
"DRUM",. 
"DUMB-,. 
"EARN", 
"EDGE", 
"ELSE", 
•EVER^, 
•FAIR^, 
•FAWN^, 
•FEND", 
"FILM", 
"FIST", 
"FLEA", 
"FLUE", 
"FONT", 
"FORT", 
"FREE", 
"FUND", 



"BIRD' 

"BLOC 

"BOCA" 

•BOLD' 

"BCiW 

•BOSE' 

"BRAG 

"BUCK' 

"BUOY 

•BUSS 

•CAKE 

"CARE 

"CAVE 

"CHAW' 

"CHUB' 

"CLAW 

•COAT 

•COIL 

"CCME 

"CORN 

"CREW 

"CULT' 

"DADE' 

"DARK" 

"DAWN" 

"DECK" 

"DENY" 

■DING" 

fDOCK* 

"DOOR" 

"DRAB" 

"DUAL" 

"DUNE" 

"EASE" 

"EDGY" 

■EMIL* 

*EVIL- 

■FAKE" 

"FEAR" 

■FERN' 

-FIND' 

"FITS' 

"FLED' 

"FOAL' 

"FOOD' 

"FOSS' 

"FRET' 

"FUNK' 



"BITE", 

"BLOT" 

"BOCK- 

"BOLT" 

"BOOK- 

■BOSS" 

"BRAN" 

■BUDD" 

•BURG" 

"BUST" 

■CALF" 

•CARL" 

•CEIL" 

"CHEF" 

"CHUG" 

■CLAY" 

•COCA" 

"COIN" 

"COOK" 

"COST" 

•CRIB" 

"CUNY" 

"DALE" 

"DARN- 

"DAYS" 

"DEED" 

"DESK" 

"DINT" 

■DOES" 

■DORA" 

"DRAG" 

"DUCK" 

"DUNK" 

•EAST" 

"EDIT" 

•EMIT^ 

rSYBD^ 

"FALL" 

■FEAT" 

■FEST^ 

•FINE^ 

•FIVE^ 

"FLEW 

"FOAM 

"FOOL 

"FOUL' 

"FREY 

"FURY' 



"BITS", 

"BLOW" 

"BODE" 

"BCMB" 

-BOOM" 

"BOTH" 

"BRAY" 

"BUFF" 

•BURL" 

"BUSY" 

"CALL" 

"CARR" 

"CELL" 

"CHEN" 

"CHUM" 

"CLOD" 

"COCK" 

"COKE" 

"COOL" 

"COVE" 

"CROW". 

"CURB" 

"DAME" 

"DART" 

"DEAD" 

"DEEM" 

fDIAL*- 

"DIRE" 

•OOLE- 

"DOSE" 

"DRAM" 

"DUCT" 

•DUSK" 

"EASY" 

"EDNA" 

•EMMA" 

■FACE^ 

■FAME^ 

"FEED^ 

■FEUD" 

•FINK^ 

"FLAG" 

"FLIT" 

"FOGY" 

"FOOT- 

•FOUR^ 

-FROG" 

•FUSE" 



"BLAB", 
"BLUE", 
"BODY", 
"BONA", 
"EXX>N", 
"BOUT", 
"BRED", 
"BULB", 
"BURN", 
"BYTE", 
"CAI>1", 
"CART", 
-CENT", 
"CHEW", 
"CITE", 
"CLOG", 
"COCO", 
"COLA", 
"COON", 
-COWL", 
"CRUD", 
"CURD", 
"DANA", 
"DASH", 
"DEAF", 
"DEER", 
"DICE", 
"DIRT", 
"DOLL", 
"DOTE", 
"DRAW", 
"DUEL", 
"DUST", 
"EBEN", 
"EGAN", 
"ENDS", 
"FACT", 
"FANG", 
■FEEL", 
"FIEF", 
■FIRE", 
"FLAK", 
■FLOC", 
"FOIL", 
" FORD- , 
"FOWL", 
"FROM", 
"FUSS", 
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-GAFF**, 


"GAGE", 


"GAIL", 


•GAIN", 


"GAIT", 


"GALA", 


"GALE", 


"GALL", 


"GALT-, 


"GAME", 


"GANG", 


"GARB", 


"GARY", 


"GASH", 


"GATE", 


"GAUL", 


-GAUR", 


"GAVE", 


"GAWK", 


"GEAR", 


"GELD", 


"GENE", 


"GENT", 


"GERM", 


"GETS", 


"GIBE", 


"GIFT", 


"GILD", 


"GILL", 


"GILT", 


•GINA", 


"GIRD", 


"GIRL", 


"GIST", 


"GIVE", 


"GLAD", 


-GLEE", 


"GLEN", 


"GLIB", 


"GLOB", 


"GW3M", 


■GLOW", 


"GLUE", 


"GLUM", 


"GLUT", 


"GOAD", 


"GOAL", 


"GOAT", 


"GOER", 


"GOES", 


"GOLD", 


"GOLF", 


"GONE", 


"GONG", 


"GOOD", 


-GOOF", 


"GORE", 


■GORY", 


"60SH" , 


"GOUT", 


"GOWN", 


"GRAB", 


"GRAD", 


"GRAY", 


"GREG", 


"GREW", 


-GREY", 


"GRID", 


"GRIM", 


"GRIN", 


"GRIT", 


"GROW", 


"GRUB", 


"GULF", 


"GULL", 


•GUNK", 


"GURU", 


"GUSH", 


"GUST", 


"GWEN", 


"GWVN", 


"HAAG", 


"HAAS", 


"HACK", 


"HAIL", 


"HAIR", 


"HALE", 


"HALF", 


"HALL", 


"HALO", 


•HALT", 


•HAND", 


"HANG", 


"HANK", 


"HANS", 


"HARD", 


"HARK", 


"HARM", 


"HART", 


"HASH", 


"HAST", 


"HATE", 


"HATH", 


"HAUL", 


"HAVE", 


"HAWK", 


"HAYS", 


"HEAD", 


"HEAL", 


"HEAR", 


"HEAT", 


"HEBE", 


-HECK", 


"HEED", 


"HEEL", 


"HEFT", 


"HELD", 


"HELL", 


"HEI>4", 


"HERB", 


"HERD", 


"HERE", 


•HERO", 


"HERS", 


"HESS", 


"HEWN", 


"HICK", 


"HIDE", 


"HIGH", 


"HIKE", 


"HILL", 


"HILT"," 


■HIND", 


"HINT", 


"HIRE", 


"HISS", 


"HIVE", 


"HOBO", 


"HOCK", 


"HOFF", 


"HOLD", 


"HOLE", 


"HOLM", 


"HOLT", 


"HC3ME", 


"HONE", 


"HONK", 


"HOOD", 


"HOOF", 


"HOOK", 


"HOOT", 


"HORN", 


"HOSE", 


"HOST", 


"HOUR", 


"HOVE", 


"HOWE", 


"HOWL", 


"HOYT-, 


"HUCK", 


"HUED", 


"HUFF", 


"HUGE", 


"HUGH", 


"HUGO", 


"HULK", 


"HULL", 


"HUNK", 


"HUNT", 


"HURD", 


"HURL", 


"HURT", 


"HUSH"/ 


"HYDE", 


"HYMN", 


"IBIS", 


"ICON", 


"IDEA", 


"IDLE", 


-IFFY", 


"INCA", 


"INCH", 


"INTO", 


"IONS", 


"IOTA", 


"IOWA", 


"IRIS", 


"IRMA", 


"IRON", 


■ISLE", 


"ITCH", 


"ITEM", 


"IVAN", 


"JACK" , 


"JADE", 


•JAIL", 


•JAKE=, 


"JANE", 


•^JAVA", 


"JE.^N", 


"JEFF", 


"JERK", 


"JESS", 


"JEST", 


"JIBE", 


■JILL", 


"JILT", 


"JIVE", 


"JOAN", 


"JOBS", 


"JOCK", 


•JOEL^, 


"JOEY", 


"JOHN", 


"JOIN", 


"JOKE", 


"JOLT", 


"JOVE", 


"JUDD", 


"JUDE", 


"JUDO", 


"JUDY", 


"JUJU", 


"JUKE", 


"JULY", 


"JUNE", 


"JUNK", 


"JUNO", 


"JURY", 


■JUST", 


"JUTE", 


"KAHN", 


"KALE", 


"KANE", 


"KANT", 


"KARL", 


"KATE", 
•KICK", 


"KEEL", 


"KEEN", 


"KENO", 


"KENT"., 


"KERN", 


"KERR", 


"KEYS", 


■KILL^, 


"KIND", 


"KING", 


"KIRK", 


"KISS", 


"KITE", 


"KLAN", 


•KNEE", 


■KNEW", 


"KNIT", 


■KNOB", 


"KNOT", 


"KNOW", 


•KOCH" , 


"KONG", 


•KUDO^, 


■KURD^, 


"KURT", 


■KYLE", 


"LACE", 


•LACK", 


"LACY", 


"LADY", 


"LAID", 


•LAIN", 


"LAIR", 


■LAKE", 


"LAMB", 


"LAME?, 


"LAND", 


"LANE", 


"LANG", 


■LARD", 


"LARK", 


"LASS", 


"LAST", 


"LATE", 


"LAUD", 


"LAVA", 


"LAWN", 


"LAWS", 


"LAYS", 


"LEAD", 


"LEAF", 


"LEAK", 


"LEAN", 


"LEAR", 


"LEEK", 


"LEER", 


■LEFT", 


"LEND", 


"LENS", 


"LENT", 


"LEON", 


"LESK", 


"LESS", 


"LEST", 


■LETS", 


"LIAR", 


"LICE", 


"LICK", 


"LIED", 


"LIEN", 


"LIES", 


"LIEU", 


■LIFE", 


■LIFT", 


"LIKE", 


"LILA", 


"LILT", 


"LILY", 


"LIMA", 


"LIMB", 


■LIME", 


■LIND", 


"LINE", 


"LINK", 


"LINT", 


"LIW", 


"LISA", 


"LIST", 


"LIVE", 


"LOAD", 


"LOAF", 


"LOAM", 


"LOAN", 


"LOCK", 


"LOFT", 


"LOGE", 


•LOIS", 


•LOLA", 


"LONE", 


"LONG", 


"LOOK", 


"LOON", 


"LOOT", 


•LORD", 


"LORE", 


"LOSE", 


"LOSS", 


"LOST", 


"LOUD", 


"LOVE", 


"LOWE", 


"LUCK", 


•^LUCY", 


"LUGE", 


"LUKE", 


"LULU", 


"LUND", 


"LUNG", 


"LURA", 


•LURE", 


"LURK", 


"LUSH", 


"LUST", 


"LYLE", 


"LYNN", 


"LYON", 


"LYRA", 


"MACE", 


"MADE", 


"MAGI", 


"MAID", 


"MAIL", 


"MAIN", 


"MAKE", 


■MALE", 


"MALI", 


"MALL*, 


"MALT", 


"MANA", 


"MANN", 


"MANY", 


' "MARC", 


"MARE", 


•MARK", 


"MARS", 


"MART", 
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"MARY", 


"MASH", 


•MASK", 


"MASS", 


"MAST", 


"MATE"," 


"MATH", 


"MAUL", 


"MAYO", 


"MEAD", 


"MEAL", 


"MEAN", 


"MEAT", 


"MEEK", 


"ME^T", 


"MELD", 


"MELT", 


"MEMO", 


"MEND", 


•MENU", 


•MERT", 


•MESH", 


"MESS", 


"MICE", 


"MIKE", 


"MILD", 


"MILE", 


"MILK", 


"MILL", 


"MILT",. 


_"MIMI", 


"MIND", 


"MINE", 


"MINI", 


"MINK", 


"MINT", 


•MIRE", 


"MISS", 


"MIST", 


"MITE", 


"MITT", 


"MOAN", 


"MOAT", 


"MOCK", 


"MODE"., 


"MOLD", 


"MOLE", 


•fMOLL", 


"MOLT", 


"MONA", 


"MONK*?, 


"MONT", 


"MOOD", 


"MOON", 


"MOOR", 


"MOOT", 


"MORE", 


"MORN", 


"MORT", 


"MOSS", 


"MOST", 


"MOTH", 


"MOVE", 


"MUCH", 


"MUCK", 


"MUDD", 


"MUFF", 


"MULE", 


"MULL", 


"MURK", 


"MUSH", 


"MUST", 


"MUTE", 


"MUTT", 


"MYRA", 


"MYTH", 


"NAGY", 


"NAIL", 


"NAIR", 


"NAME", 


"NARY", 


"NASH", 


"NAVE", 


"NAVY", 


"NEAL", 


"NEAR", 


"NEAT", 


"NECK", 


"NEED", 


"NEIL", 


"NELL", 


"NEON", 


"NERO", 


"NESS", 


■NEST", 


"NEWS", 


"NEWT", 


"NIBS", 


"NICE", 


"NICK", 


"NILE", 


"NINA", 


"NINE", 


"NOAH", 


"NODE", 


"NOEL", 


"NOLL", 


"NONE", 


"NOOK", 


■NOON^, 


"NORM", 


"NOSE", 


"NOTE", 


"NOUN", 


"NOVA", 


"NUDE", 


"NULL", 


■NUMB", 


"OATH", 


"OBEY", 


"OBOE", 


"ODIN", 


"OHIO", 


"OILY", 


"OINT", 


"OKAY", 


"OLAF", 


"OLDY", 


"OLGA", 


"OLIN", 


"OMAN", 


"OMEN", 


"OMIT", 


■ONCE", 


"ONES", 


"ONLY", 



httpy/www,ietforg/rfc/ifcl760;txt 



9/16/99 



rfcl760.txt at www.tetf.org Page 9 of 10 



"ONTO", 


"ONUS", 


"ORAL", 


"ORGY", 


"OSLO" , 


"OTIS", 


"OTTO", 


"OUCH", 


"OUST" , 


"OUTS", 


"OVAL", 


"OVEN", 


"OVER", 


"OWLY", 


"OWNS", 


■QUAD", 


"QUIT"/ 


"QUOD", 


"RACE", 


"RACK", 


"RACY", 


"RAFT", 


"RAGE", 


"RAID", 


"RAIL", 


"RAIN", 


"RAKE", 


"RANK", 


"RANT", 


"RARE", 


"RASH", 


"RATE", 


"RAVE", 


"RAYS", 


"READ", 


"REAL", 


"REAM", 


"REAR", 


"RECK", 


"REED", 


"REEF", 


"REEK", 


"REEL", 


"REID", 


"REIN", 


"RENA", 


"REND", 


"RENT", 


"REST", 


"RICE", 


"RICH", 


"RICK", 


"RIDE", 


"RIFT", 


"RILL", 


"RIME", 


"RING", 


■RINK", 


"RISE", 


"RISK", 


"RITE", 


"ROAD", 


"ROAM", 


"ROAR", 


-ROBE", 


"ROCK", 


"RODE", 


"ROIL", 


"ROLL", 


"ROME", 


"ROOD", 


"ROOF", 


"ROOK", 


"ROOM", 


"ROOT", 


-ROSA", 


"ROSE", 


"ROSS", 


"ROSY", 


"ROTH-, 


"ROUT", 


"ROVE", 


"ROWE", 


"ROWS", 


"RUBE", 


"RUBY", 


"RUDE", 


"RUDY", 


"RUIN", 


"RULE", 


"RUNG", 


"RUNS", 


"RUNT", 


"RUSE" , 


"RUSH", 


"RUSK", 


"RUSS", 


"RUST", 


"RUTH", 


"SACK", 


"SAFE", 


"SAGE", 


"SAID", 


"SAIL", 


"SALE", 


"SALK", 


"SALT", 


"SAME", 


"SAND", 


"SANE", 


"SANG", 


"SANK", 


"SARA", 


"SAUL", 


"SAVE", 


"SAYS", 


"SCAN", 


"SCAR", 


"SCAT", 


"SCOT", 


"SEAL", 


"SEAM", 


"SEAR", 


"SEAT", 


"SEED", 


"SEEK", 


"SEEM", 


"SEEN", 


"SEES", 


"SELF", 


"SELL", 


"SEND", 


"SENT", 


"SETS", 


"SEWN", 


•SHAG", 


"SHAM", 


"SHAW", 


"SHAY", 


"SHED", 


"SHIM"> 


"SHIN", . 


"SHOD", 


"SHOE", 






OMUN , 


** 011110** 

dnUU , 


"SICK" , 


"SIDE" , 


"SIFT", 


"SIGH", 


"SIGN", 


"SILK", 


"SILL", 


"siLO-r 


-SILT", 


"SINE", 


"SING", 


-SINK-, 


"SIRE", 


"SITE", 


"SITS", 


"SITU", 


"SKAT", 


"SKEW", 


"SKID", 


"SKIM", 


"SKIN", 


-SKIT", 


-SLAB", 


"SLAM", 


"SLAT", 


"SLAY", 


"SLED", 


"SLEW-, 


"SLID", 


"SLIM", 


•SLIT", 


•SLOB-, 


"SLOG", 


"SLOT", 


"SLOW", 


"SLUG-, 


"SLUM", 


"SLUR", 


"SMOG", 


"SMUG", 


-SNAG", 


"SNOB", 


"SNOW", 


•Snub-, 


"SNUG", 


"SOAK", 


-SOAR", 


-SOCK", 


"SODA", 


"SOFA", 


"SOFT", 


"SOIL", 


"SOLD", 


"SOME", 


-SONG", 


"SOON", 


"SOOT", 


"SORE", 


"SORT", 


"SOUL", 


"SOUR", 


"SOWN", 


•STAB", 


"STAG", 


"STAN", 


"STAR", 


"STAY", 


•STEM", 


"STEW", 


"STin".,.. 


•STOW", 


"STUB", 


-STUN", 


"SUCH", 


■SUDS", 


"SUIT", 


"SULK", 


"SUMS", 


"SUNG", 


"SUNK", 


"SURE", 


"SURF", 


"SWAB", 


"SWAG", 


"SWAM", 


"SWAN", 


"SWAT", 


"SWAY", 


"SWIM", 


"SWUM", 


"TACK-, 


"TACT", 


"TAIL", 


"TAKE", 


"TALE", 


"TALK", 


"TALL", 


"TANK", 


•TASK", 


"TATE", 
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•TAUT", "TEAL", "TEAM", "TEAR", "TECH", "TEEM", "TEEN", "TEET", 

"TELL", "TEND", "TENT", "TERM", "TERN", "TESS^, •TEST^, •THAN", 

•THAT", "THEE*, "THEM", "THEN", "THEY", "THIN", "THIS", "THUD", 

•THUG", "TICK^, •TIDE^, "TIDY^, "TIED", "TIER", "TILE", "TILL^, 

"TILT", "TIME",* "TINA", "TINE", "TINT", "TINY", "TIRE", "TOAD", 

•TOGO^, -TOIL", •TOLD", "TOLL", "TONE", "TONG", "TONY", "TOOK", 

•TOOL", "TOOT", "TORE", "TORN", "TOTE", "TOUR", "TOUT^, "TOWN", 

•TRAG", "TRAM", •TRAY", •TREE^, •TREK^, "TRIG^, "TRW, "TRIO", 

■TROD", "TROT",. "TROY", •TRUE^, •TUBA^, •TUBE*, "TUCK"", "TUFT", 

•TUNA", "TUNE", "TUNG", "TURF", "TURN", "TUSK", "TW16», •TWIW, 

•TWIT^, •ULAN", •UNIT", "URGE", "USED", "USER", "USES", "UTAH", 

"VML", "VAIN", •VALE", "VARY^, "VASE", "VAST^, •'VEAL", •VEDA", 

"VEIL", "VEIN", "VEND", "VENT", "VERB", "VERY", "VETO", "VICE", 

"VIEW", "VINE", "VISE-, "VOID*-, •VOLT^, "VOTE*, •WAOC, •WADE^, 

•WAGE", "WAIL"., "WAIT", "WAKE", "WALE^, "WALK", "WALL", "WALT", 

"WAND", "WANE", "WANG", "WANT", "WARD", "WARM", "WARN", "WART", 

"WASH", "WAST*?, "WATS", "WATT", "WAVE", "WAVY", "WAYS"., "WEAK", 

"WEAL", "WEAN", "WEAR", "WEED", "WEEK", "WEIR-, -WELD", "WELL", 

"WELT", "WENT",. "WERE", •WERT", "WEST"?, "WHAM", "WHAT", "WHEE", 

•WHEN", "WHET", "WHOA", "WHCM", "WICK", "WIFE", "WILD", "WILL", 

•WIND",- "WINE", "WING", "WINK", "WINO", "WIRE", •WISE", "WISH", 

"WITH", "WOLF", "WONT", "WOOD", "WOOL", •WORD", "WORE", "WORK", 

"WORM", "WORN", "WOVE", "WRIT", "WYNN", "YALE", "YANG", "YANK", 

-YARD", "YARN", "YAWL", "YAWN", "YEAH", "YEAR", "YELL", "YOGA", 

"YOKE" ); 
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HTTP Authentication: Basic and Digest Access Authentication 



Status of this Memo 



This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards'* |STD 1) for the standardization state 
and status of this protocol. Distribution of this memo Is unlimited. 
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•HTTP/1.0", Includes the specification for a Basic Access 
Authentication scheme. This scheme is not considered to be a secure 
method of user authentication (unless used in conjunction with some 
external secure system such as SSL [5]), as the user name and 
password are passed over the network as cleartext. 

This document also provides the specification for HTTP's - 
authentication framework, the original Basic authentication scheme 
and a scheme based on cryptographic hashes, referred to as "Digest 
Access Authentication" . It is therefore also Intended :to serve as a 
replacement for RFC 2069 (6] , Some optional elements specified by 
RFC 2069 have been removed from this specification due to problems 
found since its publication; other new elements have been added for 
compatibility, those new elements have been made optional, but are 
strongly recommended. 
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Like Basic, Digest access authentication verifies that both parties 
to a communication know a shared secret (a password); unlike Basic,, 
this verification can be done without sending the password in the 
clear, which is Basic's biggest weakness. As with most other 
authentication protocols, the greatest sources of risks are usually 
found not in the core protocol itself but in policies and procedures 
surrounding its use. 
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1 Access Authentication 

1.1 Reliance on the HTTP/ 1.1 Specification 

This specification Is a companion to the HTTP/1.1 specification (2). 
It uses the augmented BNF section 2.1 of that document, and relies on 
both the non-terminals defined in that document and other aspects of 
the HTTP/1,1 specification. 

1.2 Access Authentication Framework 

HTTP provides a simple challenge-response authentication mechanism 
that MAY be used by a server to challenge a client request and by a 
client to provide authentication information. It uses an extensible, 
case-insensitive token to identify the authentication scheme, 
followed by a comma-separated list of attribute-value pairs which 
carry the parameters necessary for achieving authentication via that 
scheme. 

auth-scheme «> token 

auth-param - token ( token I quoted-string ) 

The 401 (Unauthorized) response message Is used by an origin server 
to challenge the authorization of a user agent. This response MUST 
include a WWW-Authentlcate header field containing at least one 
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challenge applicable to the requested resource. The 407 (Proxy 
Authentication Required) response message Is used by a proxy to 
challenge the authorization of a client and MUST include a Proxy- 
Authenticate header field containing at least one challenge 
applicable to the proxy for the requested resource. 

challenge » auth-scheme 1*SP llauth-param 

Note: User agents will need to take special care in parsing the WWW- 
Authenticate or Proxy-Authenticate header field value if it contains 
more than one challenge, or if more than one HWW-Authenticate header 
field is provided, since the contents of a challenge may itself 
contain a comma -separated list of authentication parameters. 

The authentication parameter realm is defined for all authentication 
schemes : 

realm =» "realm" "«■" realm-value 

realm-value - quoted-strlng. 
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The realm directive | case-insensitive) is required for all 
authentication schemes that issue a challenge. The realm value 
(case-sensitive), in combination with the canonical ropt URL (the 
absoluteURI for the server whose abs^path Is enqpty; see section 5.1.2 
of [2]) of the server being accessed, defines the protection space. 
These realms allow the protected resources on a server to be 
partitioned into a set of protection spaces, each with its own 
authentication scheme and/or authorization database. The realm value 
is a string, generally assigned by the origin server, which may have 
additional semantics specific to the authentication scheme. Note that 
there may be multiple challenges with the same auth-scheme but 
different realms. 

A user agent that wishes to authenticate itself with an origin 
server — usually, but not necessarily, after receiving a 401 
(Unauthorized) — MAY do so by including an Authorization header field 
with the request. A client that wishes to authenticate Itself with a 
proxy— usually, but not necessarily, after receiving a 407 (Proxy 
Authentication Required) — MAY do so by including a Proxy- 
Authorization header field with the request. Both the Ai/thorlzation 
field value and the Proxy-Authorization field value consist of 
credentials containing the authentication information of the client 
for the realm of the resource being requested. The user agent MUST 
choose to use one of the challenges with the strongest auth-scheme it 
understands and request credentials from the user based upon that 
challenge. ^ 

credentials auth-scheme fauth-pararo 

Note that many browsers will only recognize Basic and will require 
that it be the first auth-scheme presented. Servers should only 
include Basic If It is minimally acceptable. 

The protection space determines the domain over which credentials can 
be automatically applied. If a prior request has been authorized, the 
same credentials MAY be reused for all other requests within that 
protection space for a period of time determined by the 
authentication scheme, parameters, and/ or user preference. Unless 
otherwise defined by the authentication scheme, a single protection 
space cannot extend outside the scope of its server. 

If the origin server does not wish to accept the credentials sent 
with a request, it SHOULD return a 401 (Unauthorized) response. The 
response MUST Include a WWW-Authenticate header field containing at 
least one (possibly new) challenge applicable to the requested 
resource. If a proxy does not accept the credentials sent with a 
request, it SHOULD return a 407 (Proxy Authentication Required). The 
response MUST include a Proxy-Authenticate header field containing a 



httpy/www.ic8.uci.edu/puWietf7ht1p^rfc2617.txt 



mem 



rfc2617.txtatwww.ics.uci.edu 



Franks, et al. Standards Track (Page 4) 



RFC 2617 HTTP Authentication June 1999 



(possibly new) challenge applicable to the proxy for the requested 
resource. 

The HTTP protocol does not restrict applications to this simple 
challenge-response mechanism for access authentication. Additional 
mechanisms MAY be used, such as encryption at the transport level or 
via message encapsulation, and with additional header fields 
specifying authentication information. However, these additional 
mechanisms are not defined by this specification. 

Proxies MUST be completely transparent regarding user agent 
authentication by origin servers. That is, they must forward the 
HWW-Authenticate and Authorization headers untouched, and follow the 
rules found in section 14.8 of (2J . Both the Proxy-Authenticate and 
the Proxy-Authorization header fields are hop-by-hop headers (see 
section 13.5.1 of (2) ) . 

2 Basic Authentication Scheme 

The "basic" authentication scheme is based on the model that the 
client must authenticate itself with a user-ID and a. password for 
each realm. The realm value should be considered an opaque string 
which can only be compared for equality with other realms on that 
server. The server will service tho request only if it can validate 
the user-ID and password for the protection space of the Request-URI. 
There are no optional authentication parameters. 

For Basic, the framework above is utilized as follows: 

challenge - "Basic" realm 
credentials » "Basic" basic-credentials 

Upon receipt of an unauthorized request for a URl* within the 
protection space, the origin server MAY respond with a challenge like 
the following: 

www-Authenticate: Basic reala*-"WallyWorld" 

where "WallyWorld" Is the string assigned by the server to identify 
the protection space of the Request-URI. A proxy may respond with the 
same challenge using the Proxy-Authenticate header field. 

To receive authorization, the client sends the user id. and password, 
separated by a single colon (.":") character, within a base64 (7) 
encoded string in the credentials. 

basic-credentials " base64-user-pass 

base64-user-pass <ba8e64 (4} encoding of user-pass. 



Standards Track [Page 5] 



HTTP Authentication June 1999 



except not limited to 76 char/line> 
user-pass - userld ":" password 
userid - ♦<TEXT excluding ":"> 

password « *TEXT 

Userids might be case sensitive. 

If the user agent wishes to send the userid "Aladdin* and password 
httpyAvww.ics.uci.cdu/pub/ictClittp/rfc26 17.txt 
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"open sesame". It would use the following header field: 
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZCH- 

A client SHOULD assume that all paths at or deeper than the depth of 
the last symbolic element in the path field of the Requeat-URI also 
are within the protection space specified by the Basic realm value of 
the current challenge. A client MAY preemptively send the 
corresponding Authorization header with requests for resources in 
that space without receipt of another challenge from the server. 
Similarly, when a client sends a request to a proxy, it may reuse a 
userid and password in the Proxy-Authorization header field without 
receiving another challenge from the proxy server. See section 4 for 
security considerations associated with Basic authentication. 



3 Digest Access Authentication Scheme 



3.1 Introduction 



3.1.1 Purpose 



The protocol referred to as "HTTP/l.O" includes the specification for 
a Basic Access Authentication scheme [1]. That scheme is not 
considered to be a secure method of user authentication, as the user 
name and password are passed over the network in an unencrypted form. 
This section provides the specification for a scheme that does not 
send the password in cleartext, referred to as "Digest Access 
Authentication" . 



The Digest Access Authentication scheme is not intended to be a 
complete answer to the need for security in the World Wide Web. This 
scheme provides no encryption of message content. The Intent Is 
simply to create an access authentication method that avoids the most 
serious flaws of Basic authentication. 

3.1.2 Overall Operation 

Like Basic Access Authentication, the Digest scheme is based on a 
simple challenge-response paradigm. The Digest scheme challenges 
using a nonce value. A valid response contains a checksum (by 
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t> default, the MD5 checksum) of the username, the password, the given 

nonce value, the -HTTP method, and the requested URI, In this way, the 
password is never sent in the clear. Just as with the Basic scheme, 
' username and password must be prearranged in some fashion not 

addressed by this^ document. 

3.1.3 Representation of digest values 

An optional header allows the server to specify the algorithm used to 
create the checksum or digest. By default the MD5 algorithm is used 
and that is the only algorithm described in this document. 

For the purposes ..of this document, an MD5 digest of 128 bits is 
represented as 32 ASCII printable characters. The bits in the 128 bit 
digest are converted from most significant to least significant bit, 
four bits at a time to their ASCII presentation as follows. Each four 
bits is represented by its familiar hexadecimal notation from the 
characters 0123456789abcdef . That is, binary 0000 gets represented by 
the character 'O*, 0001, by and so on up to the representation 

of 1111 as 'f. 



3.1.4 Limitations 



The Digest authentication scheme described in this document suffers 
from many known limitations. It is intended as a replacement for 
Basic authentication and nothing more. It is a password-based systei 
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and (on the server side) suffers from all the same problems of any 
password system. In particular, no provision is made in this protocol 
for the initial secure arrangement between user and server to 
establish the user's password. 

Users and Implementors should be aware that this protocol is not as 
secure as Kerberos, and not as secure as any client-side private-key 
scheme. Nevertheless it is better than nothing, better than what is 
commonly used with telnet and ftp, and better than Basic 
authentication. 

3.2 Specification of Digest Headers 

The Digest Access Authentication scheme is conceptually similar to 
the Basic scheme. The formats of the modified HWW-Authenticate header 
line and the Authorization header line are specified below. In 
addition, a new header, Authentication-Info, is specified. 
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3.2.1 The www-Authenticate Response Header 

If a server receives a request for an access-protected object, and an 
acceptable Authorization header is not sent, the server responds with 
a "401 Unauthorized" status code, and a WWW-Authenticate header as 
per the framework defined above, which for the digest scheme is 
utilized as follows: 



challenge 
digest-challenge 



"Digest" digest-challenge 

181 realm | ( domain ] I nonce \ 

I opaque ] ) [ stale ] I ( algorithm ) | 

[ qop-optlons J | [auth-param] ) 



domain » "domain" "»" <"> URI ( 1*SP URI ') <■> 

URI - absoluteURI | abs^path 

'^once m "nonce" nonce-value 

nonce-value « quoted-strlng 

opaque » "opaque* "-• quoted-string 

stale a "stale" "■" ( "true" I "false" ) 

algorithm - "algorithm" ( "MD5" | "MDS-sess" | 
token ) 

qop-optlons « "qop" "«" <-> liqop-value <"> 

qop-value « "auth" | "auth-lnf | token 



The meanings of the values of the directives used above are as 
follows: 



realm 

A string to be displayed to users so they know which usernaroe and 
password to use. This string should contain at least the name of 
the host performing the authentication and might additionally 
Indicate the collection of users who might have access. An example 
might be "registered_usersegotham.news.com''. 

domain 

A quoted, space-separated list of URIs, as specified in RFC XURI 
[7], that define the protection space. If a URI Is an abs_path, it 
Is relative to the canonical root URL (see section 1.2 above) of 
the server being accessed. An absoluteURI in this list may refer to 
a different server than the one being accessed. The client can use 
this list to determine the set of URIs for which the same 
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authentication information may be aent; any URI that has a URI in 
this list as a prefix (after both have been made absolute) may be 
assumed to be in the same protection space. If this directive Is 
omitted or its value is empty, the client should assume that the 
protection space consists of all URIs on the responding server. 



Franks, et al. Standards Track [Page 8) 

RFC 2617 HTTP Authentication June 1999 



This directive Is not meaningful in Proxy-Authenticate headers, for 
which the protection space is always the entire proxy; if present 
it should be ignored. 

nonce 

A server-specified data-' string which should be uniquely generated 
each time a 401 response is made. It is reconuncnded that this 
string be base64 or hexadecimal data. Specifically, since the 
string is passed in the header lines as a quoted string, the 
double-quote character is not allowed. 

The contents of the nonce are Inplecentation dependent. The quality 
of the implementation depends on a good choice. A nonce might, for 
example, be constructed as the base 64 encoding of 

time-stamp HCtime-stairp ETag private-key) 

where time-stamp is a server-generated time or other non-repeating 
value, ETag is the value of the HTTP ETag header associated with 
the requested entity, and private-key is data known only to the 
server. With a nonce of this form a server would recalculate the 
hash portion after receiving the client authentication header and 
reject the request if it did not match the nonce from that header 
or if the tlme*stan^ value is not recent enough. In this way the 
server can limit the time of the nonce's validity. The inclusion of 
the ETag prevents a replay request for an updated version of the 
resource. (Note: including the IP address of the client in the 
nonce would appear to offer the server the ability to limit the 
reuse of the nonce to the same client that originally got it. 
However, that would break proxy farms, where requests from a single 
user often go through different proxies in the farm. Also, IP 
address spoofing is not that hard.) 

An implementation might choose not to accept a previously used 
nonce or a previously used digest, in order to protect. against a 
replay attack. Or, an implementation might choose to use one-time 
nonces or digests for POST or PUT requests and a time-stamp for GET 
requests. For more details on the issues involved see section 4. 
of this document. 




The nonce is opaque to the client. 



opaque 

f A string, of data, sipecif led by the server, which should be returned 

A by the client unchanged in the Authorization header of subsequent 

^ requests with URIs in the same protection space. It is recommended 

that this string be base64 or hexadecimal data. 
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stale 

A flag, indicating that the previous request from the client was 
rejected because the nonce value was stale. If stale is TRUE 
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(case-insensitive), the client may wish to simply retry the request 
with a new encrypted response, without reprompting the user for a 
new username and password. The server should only set stale to TRUC 
if it receives a request for which the nonce is invalid but with a 
valid digest for that nonce (indicating that the client knows the 
correct username/password) . If stale is FALSE, or anything other 
than TRUE, or the stale directive is not present, the username 
and/or password are invalid, and new values must be obtained. 

algorithm 

A string indicating a pair of algorithms used to produce the digest 
and a checksum. If this is not present it is assumed to be "MDS**. 
If the algorithm is not understood, the challenge should be ignored 
(and a different one used, if there is more than one). 

In this document the string obtained by applying the digest 
algorithm to the data "data* with secret "secret* will be denoted 
by KD(secret, data), and the string obtained by applying the 
checksum algorithm to the data "data" will be denoted H(data). The 
notation unq(X) means the value of the quoted-string X without the 
surrounding quotes. 

For the "MDS" and "MD5-sess" algorithms 
H(data) ° MDS (data) 

and 

KD(secret, data) » H (concat (secret, ":", data)) 

i.e., the digest is the M05 of the secret concatenated with a colon 
concatenated with the data. The "MOS-sess" algorithm is intended to 
allow efficient 3rd party authentication servers; for the 
difference in usage, see the description in section 3.2.2.2. 

qop-options 

This directive is optional, but is made so only for backward 
compatibility with RFC 2069 [6]; it SHOULD be used by all 
implementations compliant with this version of the Digest scheme. 
If present, it is a quoted string of one or more tokens indicating 
the "quality of protection" values supported by the server. The 
value "auth" indicates authentication; the value "auth-int" 
indicates authentication with integrity protection; see the 
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descriptions below for calculating the response directive value for 
the application of this choice. Unrecognized options MUST be 
ignored . 

auth*param 

This directive allows for future extensions. Any unrecognized 
directive MUST be Ignored. 

3.2.2 The Authorization Request Header 

The client is expected to retry the request, passing an Authorization 
header line, which is defined according to the framework above, 
utilized as follows. 

credentials = "Digest" digest-response 

digest-response • 1#( username | realm | nonce I dlgest-uri 

I response t ( algorithm ] | [cnonce] J 

(opaque] | [message-qop] ) 

[nonce-count] | [auth-pararo] ) 
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username = "username** username-value 

username-value - quoted-strlng 

digest-uri « "url" digest-uri-value 

digest-url-value « request-uri ; Aa specified by HTTP/1.1 

mesaage-qop - "qop" *=• qop-value 

enonce «- "cnonce" cnonce-value 

cnonce-value = nonce-value 

nonce-count = "nc" nc-value 

nc-value - 8LHEX 

response - "response" request-digest 

request-digest « <*> 32LHEX <"> 

LHBX «. "O" I "l" I "2" I "S" I 

"4" I *5" I "6" I "7" I 

-8" I "9" I "a- I »b" I 

»c" I "d" I "e" I *f" 

The values of the opaque and algorithm fields must be those supplied 
In the www-Authenticate response header for the entity being 
requested . 

response 

A string of 32 hex digits conqputed as defined below, which proves 
that the user knows a password 

username 

The user's name in the specified realm. 
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digest-uri 

The URI from Request-URI of the Request-Line; duplicated here 
because proxies are allowed to change the Request-Line in transit. 

qop 

Indicates what "quality of protection" the client has applied to 
the message. If present. Its value MUST be one of the alternatives 
the server indicated It supports in the W99W-Authentlcate header. 
These values affect the computation of the request-digest. Note 
that this is a single token, not a quoted list of alternatives as 
In WWW- Authenticate. This directive Is optional in oixJer to 
preserve backward compatibility with a minimal implementation of 
RFC 2069 [6], but SHOULD be used If the server Indicated that qop 
Is supported by providing a qop directive In the WWW-Authentlcate 
header field. 

enonce 

This MUST be specified If a qop directive Is sent (see above], and 
MUST NOT be specified if the server did not send a qop directive in 
the WWW- Authenticate header field. The cnonce-value is an opaque 
quoted string value provided by the client and used by both client 
and server to avoid chosen plaintext attacks, to provide mutual 
authentication, and to provide some message integrity protection. 
See the descriptions below of the calculation of the response- 
digest and request-digest values. 

nonce-count 

This MUST be specified if a qop directive is sent (see above), and 
MUST NOT be specified if the server did not send a qop directive in 
the www-Authenticate header field. The nc-value is the hexadecimal 
count of the number of requests (including the current request) 
that the client has sent with the nonce value in this request. For 
example. In the first request sent in response to a given nonce 
value, the client sends "nc-00000001". The purpose of this 
directive is to allow the server to detect request replays by 
maintaining, its own copy of this count - if the same nc-value is 
seen twice, then the request is a replay. See the description 
below of the construction of the request-digest value. 
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auth-param 

This directive allows for future extensions. Any unrecognized 
directive MUST be ignored. 

If a directive or its value is Improper, or required directives are 
missing, the proper response is 400 Bad Request. If the request- 
digest is Invalid, then a login failure should be logged, since 
repeated login failures from a single client may indicate an attacker 
attempting to guess passwords. 
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The definition of request-digest above indicates the encoding for its 
value. The following definitions show how the value is computed. 

3.2.2.1 Request-Digest 

If the "qop" value Is "auth" or "auth-int": 

request-digest - <-> < KD ( HlAl), unq( nonce-value) 

nc-value 
" : " unq ( cnonce-va lue ) 
unq(qop-value) 
H(A2) 

) <-> 

If the "qop" directive Is not present (this construction is for 
coii«>atibility with RFC 2069): 

request-digest «■ 

<"> < KO ( H(A1), unq (nonce-value) H(A2) ) > 

<"> 

See below for the definitions for Al and A2. 

3.2.2.2 Al 

If the -algorithm" directive's value is "MDS" or is unspecified, then 
Al is: 

Al - unq(username-value) unq (realm-value) passwd 

where 

passwd » < user's password > 

If the "algorithm" directive's value is "MD5-sess", then Al is 
calculated only once - on the first request by the client following 
receipt of a WWH-Authenticate challenge from the server. It uses the 
server nonce from that challenge, and the first client nonce value to 
construct Al ds follows: 

Al « H( unq(username-value) unq (realm-value) 

passwd ) 

":* unq{nonce-value) unq(cnonce-value) 

This creates a 'sesislon key' for the authentication of subsequent 
requests and responses which is different for each "authentication 
session", thus limiting the amount of material hashed with any one 
key. (Note: see further discussion of the authentication session In 
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section 3.3.) Because the server need only use the hash of the user 
credentials in order to create the Al value, this construction could 
be used in conjunction with a third party authentication service so 
that the web server would not need the actual password value. The 
specification of such a protocol is beyond the scope of this 
specification. 

3.2-2.3 A2 

If the "qop" directive's value is "auth" or is unspecified, then A2 
is: 

A2 » Method digest-uri-value 

If the "qop" value is "auth-int", then A2 Is: 

A2 « Method digest-uri-value H (entity-body) 

3.2.2.4 Directive values and quoted-strlng 

Note that the value of many of the directives, such as '**username- 
value", are defined as a "quoted-string*. However, the "unq" notation 
indicates that surrounding quotation marks are removed in forming the 
string Al. Thus If the Authorization header includes the fields 

username^^Mufasa", realmRmyhostetestrealm.com 

and the user Mufasa has password "Circle Of Life* then H{A1) would be 
H(Mufasa:myhost 6 testrealm.com: Circle Of Life) with no quotation marlcs 
in the digested string. 

No white space is allowed in any of the strings to which the digest 
function H(J is applied unless that white space exists in the quoted 
strings or entity body whose contents ma)ce up the string to be 
digested. For example, the string Al illustrated above must be 

Muf as a: myhoste tea trealm.com: Circle Of Life 

with no white space on either side of the colons, but with the white 
space between the words used in the passvrord value. Li)cewise, the 
other strings digested by H() must not have white space on either 
side of the colons which delimit their fields unless that white space 
was in the quoted strings or entity body being digested. 

Also note that if integrity protection is applied (qop-auth-int) , the 
H(entity-body) is the hash of the entity body, not the message body - 
It is computed before any transfer encoding is applied by the sender 
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and after it has been removed by the recipient. Note that this 
includes multipart boundaries and embedded headers in each part of 
any multipart, content-type. 

3.2.2.5 Various considerations 

The "Method" value is the HTTP request method as specified in section 
5,1.1 of (2). The "request-uri" value is the Request-URI from the 
request line as specified in section 5.1.2 of 12). This may be "*", 
an "absoluteURL" or an "abs_path" as specified in section 5.1.2 of 
[2], but it MUST agree with the Request-URI. In particular, it MUST 
be an "absoluteURL" if the Request-URI is an "absoluteURL". The 
"cnonce-value" is an optional client-chosen value whose purpose is 
to foil chosen plaintext attacks. 

The authenticating server must assure that the resource designated by 
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the "uri" directive Is the same as the resource specified in the 
Request -Line; if they are not, the server SHOULD return a 400 Bad 
Request error. (Since this may be a symptom of an attack, server 
implementers may want to consider logging such errors.) The purpose 
of duplicating information from the request URL in this field is to 
deal with the possibility that an intermediate proxy may alter the 
client's Request-Line. This altered (but presumably semantically 
equivalent) request would not result in the same digest as that 
calculated by the client. 

Implementers should be aware of how authenticated transactions 
Interact with shared caches. The HTTP/1.1 protocol specifies that 
when a shared cache (see section 13.7 of (2)) has received a request 
containing an Authorization header and a response from relaying that 
request, it MUST KOT return that response as a reply to any other 
request, unless one of two Cache-Control (see section 14.9 of (2]) 
directives was present in the response. If the original response 
included the "must -revalidate* Cache-Control directive, the cache MAY 
use the entity of that response in replying to a subsequent request, 
but MUST first revalidate it with the origin server, using the 
request headers from the new request to allow the origin server to 
authenticate the new request. Alternatively, if the original response 
included the "public* Cache-Control directive, the response entity 
MAY be returned in reply to any subsequent request. 

3,2.3 The Authentication-Info Header 

The Authentication-Info r.isader is used by the server to communicate 
some information regarding the successful authentication in the 
response. 
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Authenticationlnfo « "Authentication-Info" ";" auth-info 
auth-info «» ll(nextnonce | [ mesaage-qop ] 

I ( response-auth 1 I ( cnonce ] 

I [nonce-count] ) 
nextnonce » "nextnonce" "-" nonce-value 

response-auth « "rspauth" response-digest 

response-digest « <■> *LHEX <"> 

The value of the nextnonce directive Is the nonce the server wishes 
the client to use for a future authentication response. The server 
may send the Authentication-Info header with a nextnonce field as a 
means of implementing one-time or otherwise changing nonces. If the 
nextnonce field la present the client SHOULD use it when constructing 
the Authorization header for its next request. Failure of the client 
to do so may result In a request to re-authenticate from the server 
with the "stale-TRUE". 

Server Implementations should carefully consider the performance 
implications of the use of this mechanism; pipelined requests will 
not be possible If every response Includes a nextnonce directive 
that must be used on the next request received by the server. 
Consideration should be given to the performance vs. security 
tradeoffs of allowing an old nonce value to be used for a limited 
time to permit request pipelining. Use of the nonce-count can 
retain most of the security advantages of a new server nonce 
without the deleterious affects on pipelining. 

message-qop 

Indicates the "quality of protection" options applied to the 
response by the server. The value "auth" indicates authentication; 
the value "auth-lnt" Indicates authentication with integrity 
protection. The server SHOULD use the same value for the message- 
qop directive in the response as was sent by the client in the 
corresponding request. 
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The optional response digest In the "response-auth** directive 
supports mutual authentication — the server proves that it knows the 
user's secret, and with qop^auth-int also provides limited integrity 
protection of the response. The "response-digest** value is calculated 
as for the •* request-digest *• in the Authorization header, except that 
if "qop-auth" or is not specified in the Authorization header for the 
request, A2 is 

A2 - digest-uri-value 

and if "qop-auth-int", then A2 is 

A2 - digest-uri-value H (entity-body) 
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where "digest-uri-value*' is the value of the "url" directive on the 
Authorization header in the request. The "cnonce-value" and *nc- 
value" MUST be the ones for the client request to which this message 
is the response. The "response-auth", "cnonce", and "nonce-count* 
directives MUST BE present if "qop^auth" or "qop»auth-lnt" is 
specified. 

The Authentlcation-Info header is allowed in the trailer of an HTTP 
message transferred via chunked transfer-coding. 

3.3 Digest deration 

Upon receiving the Authorization header, the server may check its 
validity by looking up the password that corresponds to the submitted 
usemame. Then, the server must perform the same digest operation 
(e.g., MD5) performed by the client, and compare the result to the 
given request-digest value. 

Note that the HTTP server does not actually need to know the user's 
cleartext password. As long as H(A1| is available to the server, the 
validity of an Authorization header may be verified. 

The client response to a WWW- Authenticate challenge for a protection 
space starts an authentication session with that protection space. 
The authentication session lasts until the client receives another 
www-Authenticate challenge from any server in the protection space. A 
client should remember the username, password, nonce, nonce count and 
l^-^. opaque values associated with an authentication session to use to 

"s^ ' construct the Authorization header in future requests within that 

protection space. The Authorization header may.be included 
M preemptively; doing so improves server efficiency and avoids extra 

KT round trips for authentication challenges. The server may choose to 

accept the old Authorization header information, even though the 
f. nonce value Included might not be fresh. Alternatively, the server 

may return a 401 response with a new nonce value, causing the client 
to retry the request;, by specifying stalc«TRUE with this response, 
the server tells the client to retry with the new nonce, but without 
prompting for a new username and password. 

Because the client is required to return the value of the opaque 
directive given to it by the server for the duration of a session, 
the opaque data may be used to transport authentication session state 
information. (Note that any such use can also be accomplished more 
easily and safely by Including the state In the nonce.) For example, 
a server could be responsible for authenticating content that 
actually sits on another server. It would achieve this by having the 
first 401 response include a domain directive whose value includes a 
URI on the second server, and an opaque directive whose value 
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contains the state information. The client will retry the request, at 
which time the server might respond with a 301/302 redirection, 
pointing to the URI on the second server. The client will follow the 
redirection, and pass an Authorization header , including the 
<opaque> data. 

As with the basic scheme, proxies must be completely transparent in 
the Digest access authentication scheme* That is, they must forward 
the HWW-Authenticate, Authentication-Info and Authorization headers 
untouched. If a proxy wants to authenticate a client before a request 
is forwarded to the server, it can be done using the Proxy- 
Authenticate and Proxy-Authorization headers described in section 3.6 
below, 

3.4 Security Protocol Negotiatipn. 

It is useful for a server to be able to know which security schemes a 
client is capable of handling. 

It Is possible that a server may want to require Digest as its 
authentication method, even if the server does not know that the 
client supports it. A client is encouraged to fail gracefully if the 
server specifies only authentication schemes it cannot handle. 

3.5 Example 

The following example assumes that an access-protected document is 
being requested from the server* via a GET request. The URI of the 
document is '•http://www.nowhere.org/dir/index.html". Both client and 
server know that the username for this document is "Mufasa", and the 
password is "Circle Of Life" (with one space between each of the 
three words) . 

The first time the client requests the document, no Authorization 
header is sent, so the server responds with: 

HTTP/1.1 401 Unauthorized 
WWW- Authenticate: Digest 

realm-" test realmShost . com" , 

qop»"auth, auth-int", 

nonce»"dcd98b7102dd2fOe8blldOf600bfbOc093", 
opaque-*Sccc069c403ebaf9f0171e9517f40e41" 

The client may prompt the user for the username and password, after 
which it will respond with a new request, IncliKling the following 
Authorization header: 
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Authorization: Digest username«"Mufasa", 
realm»"testrealmehost . com" , 
nonce»"dod98b7102dd2f0e8blld0f600bfb0c093", 
url="/dir/ index. html", 
qop^auth, 
nc«>00000001, 
cnonce-"0a4f 113b", 

response-"6629fae4 9393a05397450978507c4efl", 
Opaque«"5ccc069c403ebaf9f0171e9517f40e41" 

3.6 Proxy-Authentication and Proxy-Authorization 



The digest authentication scheme may also be used for authenticating 
users to proxies, proxies to proxies, or proxies to origin servers by 



httpy/www.ics.uci.edu/puh/ictf7http/rfc2617.txt 



f 

9/16/99 



rfc2617.txtatwww.tcs.uci.edu 



use of the Proxy-Authenticate and Proxy- Authorization headers. These 
headers are instances of the Proxy-Authenticate and Proxy- 
Authorization headers specified in sections 10.33 and 10.34 of the 
HTTP/1.1 specification [2] and their behavior is subject to 
restrictions described there. The transactions for proxy 
authentication are very similar to those already described. Upon 
receiving a request which requires authentication, the proxy/server 
must issue the "407 Proxy Authentication Required** response with a 
"Proxy-Authenticate* header. The digest-challenge used in the 
Proxy-Authenticate header is the same as that for the WWW- 
Authenticate header as defined above in section 3.2.1. 

The client/proxy must then re-issue the request with a Proxy- 
Authorization header, with directives as specified for the 
Authorization header in section 3.2.2 above. 

On subsequent responses, the server sends Proxy-Authentication-Info 
with directives the same as those for the Authentication-Info header 
field. 

Note that in principle a client could be asked to authenticate Itself 
to both a proxy and an end-server, but never in the same response. 

4 Security Considerations 

4.1 Authentication of Clients using Basic Authentication 

The Basic authentication scheme is not a secure method of user 
authentication, nor does it in any way protect the entity, which is 
transmitted in cleartext across the physical network used as the 
carrier. HTTP does not prevent additional authentication schemes and 
encryption mechanisms from being employed to increase security or the 
addition of enhancements (such as schemes to use one-time passwords) 
to Basic authentication. 
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The roost serious flaw in Basic authentication is that it results in 
the essentially cleartext transmission of the user's password over 
the physical network. It is this problem which Digest Authentication 
attempts to address. 

Because Basic authentication involves the cleartext transmission of 
passwords it SHOULD NOT be used (without enhancements) to protect 
sensitive or valuable information. 

A common use of Basic authentication is for identification purposes 
— requiring the user to provide a user name and password as a means 
of identification, for exanv>le, for purposes of gathering accurate 
usage statistics on a server. When used in this way it is ten5>ting to 
think that there is no danger in its use if illicit access to the 
protected documents Is not a major concern. This Is only correct if 
the server issues both user name and password to the users and in 
particular does not allow the user to choose his or her own password. 
The danger arises because naive users frequently reuse a single 
passvrord to avoid the task of maintaining multiple passwords. 

If a server permits users to select their own passwords, then the 
threat is not only unauthorized access to documents on .the server but 
also unauthorized access to any other resources on other systems that 
the user protects with the same password. Furthermore, in the 
server's password database, many of the passwords may also be users* 
passwords for other sites. The owner or administrator of such a 
system could therefore expose all users of the system to the risk of 
unauthorized access to all those sites if this information is not 
maintained in a secure fashion. 

Basic Authentication is also vulnerable to spoofing by counterfeit 
servers. If a user can be led to believe that he is connecting to a 
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host containing Information protected by Basic authentication when, 
in fact, he is connecting to a hostile server or gateway, then the 
attacker can request a password, store It for later use, and feign an 
error. This type of attack is not possible with Digest 
Authentication. Server inplementers SHOULD guard against the 
possibility of this sort of counterfeiting by gateways or CGI 
scripts. In particular it is very dangerous for a server to simply 
turn over a connection to a gateway. That gateway can then use the 
persistent connection mechanism to engage In multiple transactions 
with the client while impersonating the original server in a way that 
is not detectable by the client. 

4,2 Authentication of Clients using Digest Authentication 

Digest Authentication does not provide a strong authentication 
mechanism, when compared to public key based mechanisms, for example. 
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However, it is significantly stronger than (e.g.) CRAM-MD5, which has 
been proposed for use with LDAP (10), POP and IMAP (see RFC 2195 
[9)). It is Intended to replace the much weaker and even more 
dangerous Basic mechanism. 

Digest Authentication offers no confidentiality protection beyond 
protecting the actual password. All of the rest of the request and 
response are available to an eavesdropper. 

Digest Authentication offers only limited integrity protection for 
the messages in either direction. If qop=»auth-int mechanism Is used, 
those parts of the message used in the calculation of the WWW- 
Authenticate and Authorization header field response directive values 
(see section 3.2 above) are protected. Most header fields and their 
values could be modified as a part of a man-ln-the-mlddle attack. 

Many needs for secure HTTP transactions cannot be met by Digest 
Authentication. For those needs TLS or SHTTP are more appropriate 
protocols. In particular Digest authentication cannot be used for any 
transaction requiring confidentiality protection. Nevertheless many 
functions remain for which Digest authentication is both useful and 
appropriate. Any service in present use that uses Basic should be 
switched to Digest as soon as practical. 

4.3 Limited Use Nonce Values 

The Digest scheme uses a server-specified nonce to seed the 
generation of the request-digest value (as specified in section 
3.2.2.1 above). As shown in the example nonce in section 3.2.1, the 
server is free to construct the nonce such that it may only be used 
from a particular client, for a particular resource, for a limited 
period of time or number of uses, or any other restrictions. Doing 
so strengthens the protection provided against, for example, replay 
attacks (see 4.5). However, it should be noted that ithe method 
chosen for generating and chiscking the nonce also has performance and 
resource implications. For example, a server may choose to allow 
each nonce value to be used only once by maintaining a- record of 
whether or not each recently Issued nonce has been returned and 
sending a next-nonce directive in the Authentlcation-lrifo header 
field of every response. This protects against even an immediate 
replay attack, but has a high cost checking nonce values, and perhaps 
more important will cause authentication failures for any pipelined 
requests (presumably returning a stale nonce indication). Similarly, 
Incorporating a request-specific element such as the Etag value for a 
resource limits the use of the nonce to that version of the resource 
and also defeats pipelining. Thus it may be useful to do so for 
methods with side effects but have unacceptable performance for those 
that do not. 
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4.4 Comparison of Digest with Basic Authentication 

Both Digest and Basic Authentication are very much on the weak end of 
the security strength spectrum. But a comparison between the two 
points out the utility, even necessity, of replacing Basic by Digest. 

The greatest threat to the type of transactions for which these 
protocols are used Is network snooping. This kind of transaction 
might Involve, for example, online access to a database whose use is 
restricted to paying subscribers. With Basic authentication an 
eavesdropper can obtain the password of the user. This not only 
permits him to access anythingln the database, but, often worse, 
will permit access to anything" else the user protects with the same 
pai9 sword. 

By contrast, with Digest Authentication the eavesdropper only gets 
access to the transaction in question and not to the user's password. 
The Information gained by the eavesdropper would permit a replay 
attack, but only with a request for the same document, and even that 
may be limited by the server's choice of nonce. 

4.5 Replay Attacks 

A replay attack against Digest authentication would usually be 
pointless for a simple GET request since an eavesdropper would 
already have seen the only document he could obtain with a replay. 
This is because the URI of the requested document is digested in the 
client request and the server will only deliver that document. By 
contrast under Basic Authentication once the eavesdropper has the 
user's password, any document protected by that password is open to 



Thus, for some purposes, it is necessary to protect against replay 
attacks. A good Digest implementation can do this in various ways. 
The server created "nonce* value is implementation dependent, but if 
It contains a digest of the client IP, a time-stamp, the resource 
ETag, and a private server key (as recommended above) then a replay 
attack Is not sin9>le. An attacker must convince the server that the 
request is coming from a false IP address and must cause the server 
to deliver the document to an IP address different from the address 
to which it believes It is sending the document. An attack can only 
succeed in the period before the time-stamp expires. Digesting the 
client IP and time-stamp in the nonce permits an Implementation which 
does not maintain state between transactions. 

For applications where no possibility of replay attack can be 
tolerated the server can use one-time nonce values which will not be 
honored for a second use. This requires the overhead of the server 
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remembering which nonce values have been used until the nonce time- 
stamp (and hence the digest built with It) has expired, but it 
effectively protects against replay attacks. 

An implementation must give special attention to the possibility of 
replay attacks with POST and PUT requests. Unless the server employs 
one-time or otherwise limited-use nonces and/or Insists on the use of 
the integrity protection of qop-auth-int, an attacker could replay 
valid credentials from a successful request with counterfeit form 
data or other message body. Even with the use of integrity protection 
most metadata in header fields is not protected. Proper nonce 
generation and checking provides some protection against replay of 
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previously used valid credentials, but see 4.8. 

4.6 Weakness Created by Multiple Authentication Schemes 

An HTTP/1.1 server may return multiple challenges with a 401 
(Authenticate t response, and each challenge may use a different 
auth-scheme. A user agent MUST choose to use the strongest auth- 
scheme It understands and request credentials from the user based 
upon that challenge. 

Note that many browsers will only recognize Basic and will require 
that it be the first auth-scheme presented. Servers should only 
include Basic if it Is minimally acceptable. 

When the server offers choices of authentication schemes using the 
www-Authenticate header, the strength of the resulting authentication 
is only as good as that of the of the weakest of the authentication 
schemes. See section 4.8 below for discussion of particular attack 
scenarios that exploit multiple ' authentication schemes* 

4.7 Online dictionary attacks 

If the attacker can eavesdrop, then it can test any overheard 
nonce/response pairs against a list of common words. Such a list is 
usually much smaller than the total number of possible passwords. The 
cost of coirputing the response for each password on the list is paid 
onc« for each challenge. 

The server can mitigate this attack by not allowing users to select 
passwords that are in a dictionary. 
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4.8 Man in the Middle 

Both Basic and Digest authentication are vulnerable to *raan in the 
middle* (MITM) attacks, for example, from a hostile or .compromised 
proxy. Clearly, this would present all the problems of eavesdropping. 
But it also offers some additional opportunities to the attacker. 

A possible man-in-the-middle attack would be to add a weak 
authentication scheme to the set of choices, hoping that the client 
will use one that exposes the user's credentials (e.g. password). For 
this reason, -the client should always use the strongest scheme that 
It understands from the choices offered; 

An even better MITM attack would be to remove all offered choices, 
replacing them with a challenge that requests only Basic 
authentication, then uses the. cleartext credentials from the Basic 
authentication to authenticate to the origin server using the 
stronger scheme it requested. A particularly insidious way to mount 
such a MITM attack would be to offer a "free" proxy caching service 
to gullible users. 

User agents should consider measures such as presenting a visual 
indication at the time of the credentials request of what 
authentication scheme is to be used, or remembering the strongest 
authentication scheme ever requested by a server and produce a 
warning message before using a weaker one. It might also be a good 
idea for the user agent to be configured to demand Digest 
authentication in general, or from specific sites. 
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Or, a hostile proxy might spoof the client into making a request the 

attacker wanted rather than one the client wanted. Of course, this is 

still much harder than a comparable attack against Basic 
Authentication. 

4.9 Chosen plaintext attacks 

With Digest authentication, a MITM or a malicious server can 
arbitrarily choose the nonce that the client will use to compute the 
response. This la called a "chosen plaintext* attack. The ability to 
choose the nonce is known to make cryptanalysis much easier [8]. 

However, no way to analyze the MD5 one-way function used by Digest 
using chosen plaintext is currently known. 

The countermeasure against this attack is for clients to be 
configured to require the use of the optional "cnonce" dlrective; 
thls allows the client to vary the input to the hash in a way not 
chosen by the attacker. . . 
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4.10 Precomputed dictionary attacks 

With Digest authentication. If the attacker can execute a chosen 
plaintext attack, the attacker can precomputo the response for many 
common words to a nonce of its choice, and store a dictionary of 
(response, password) pairs. Such precomputatlon can often be done in 
parallel on many machines- It can then use the chosen plaintext 
attack to acquire a response corresponding to that challenge, and 
5ust look up the password In the dictionary. Even If roost passwords 
are not in the dictionary, some might bo. Since the attacker gets to 
pick the challenge, the cost of computing the response for each 
password on the list can be amortized over finding many passwords. A 
dictionary with 100 million pas sword /response pairs would take about 
3.2 gigabytes of disk storage. 

The countermeasure against^this attack Is to for clients to be 
configured to require the use of the optional *cnonce" directive. 

4.11 Batch brute force attacks 

With Digest authentication, a MITM can execute a chosen plaintext 
attack, and can gather responses from many users to the same nonce. 
It can then find* all the passwords within any subset of password 
space that would generate one of the nonce/ response pairs In a single 
pass over that space. It also reduces the time to find the first 
passvrord by a factor equal to the number of nonce/response pairs 
gathered. This search of the password space can often be done In 
parallel on many machines, and even a single machine can search large 
subsets of the password space very quickly — reports exist of 
searching all* passwords with six or fewer letters In a few hours. 

The countermeasure against this attack Is to for clients to be 
configured to require the use of the optional "cnonce" directive. . 

4.12 Spoofing by Counterfeit Servers 

Basic Authentication is vulnerable to spoofing by counterfeit 
servers. If a user can be led to believe that she Is connecting to a 
host containing Information protected by a password she knows, when 
in fact she is connecting to a hostile server, then the hostile 
server can request a password, store It away for later use, and feign 
an error. This typo of attack is more difficult with Digest 
Authentication but the client must know to demand that Digest 
authentication be used, perhaps using some of the techniques 
described above to counter "man-ln-the-mlddle" attacks. Again, the 
user can be helped in detecting this attack by a visual indication of 
the authentication mechanism in use with appropriate guidance in 
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Interpreting the Implications of each scheme. 
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4.13 Storing passwords 

Digest authentication requires that the authenticating agent (usually 
the server) store some data derived from the user's name and password 
in a "password file" associated with a given realm. Normally this 
might contain pairs consisting of username and H(A1), where H(A1) is 
the digested value of the username, realm, and password as described 
above. 

The security implications of this are that if this password file Is 
compromised, then an attacker gains immediate access to documents on 
the server using this realm. Unlike, say a standard UNIX password 
file, this Information need not be decrypted in order to access 
documents In the server realm associated with this file. On the other 
hand, decryption, or more likely a brute force attack, would be 
necessary to obtain the user's password. This is the reason that the 
realm is part of the digested data stored In the password file. It 
means that if one Digest authentication password file is compromised, 
it does not automatically compromise others with the same username 
and password (though it does expose them to brute force attack). 

There are two Important security consequences of this. First the 
password file must be protected as if it contained unencrypted 
passwords, because for the purpose of accessing documents in its 
realm. It effectively does. 

A second consequence of this is that the realm string should be 
unique among all realms which any single user is likely to use. In 
particular a realm string should include the name of the host doing 
the authentication. The inability of the client to authenticate the 
server is a weakness of Digest Authentication. 

4.14 Summary 

By modern cryptographic standards Digest Authentication is weak. But 
for a large range of purposes it is valuable as a replacement for 
Basic Authentication. It remedies some, but not all, weaknesses of 
Basic Authentication. Its strength may vary depending on the 
implementation. In particular the structure of the nonce (which is 
dependent on the server implementation) may affect the ease of 
mounting a replay attack. A range of server options is appropriate 
since^ for example, some implementations may be willing to accept the 
server overhead of one-time nonces or digests to eliminate the 
possibility of replay. Others may satisfied with a nonce like the one 
recommended above restricted to a single IP address and a single ETag 
or with a limited lifetime. 



Franks, et al. Standards Track (Page 26) . 



RFC 2617 HTTP Authentication June 1999 



The bottom line is that ♦any* compliant Implementation will be 
relatively weak by cryptographic standards, but *any* compliant 
implementation will be far superior to Basic Authentication. 

5 Sample implementation 

The following code Implements the calculations of H(A1), H(A2), 
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request-digest and response-digest, and a test program which computes 
the values used in the example of section 3.5. It uses the MDS 
implementation from REX: 1321. 

rile "digcalc.h": 

Idefine HASHLEN 16 ^ 

typedef char HASH [HASHLEN) ; 

Idefine HASHHEXLEN 32 

typedef char HA5HHEX[HASHHEXLEN+1] ; 

Idefine IH 

Idefine OUT 

calculate H(A1] as per HTTP Digest spec */ 
void DigestCalcHAl ( 
IN char * pszAlg, 
IN char * pszUserName, 
IN char * pszRealm, 
IN char * pszPass%rord, 
IN char ♦ pszNonce, 
IN char * pszCNonce, 
OUT HA5HHEX SessionKey 

); 

/• calculate request-digest/response-digest as per HTTP Digest spec */ 
void DigestCalcResponse ( 

IN HASHHEX HAl, /* H(A1) */ 

IN char * pszNonce, /* nonce from server */ 

IN char * pszNonceCount, /♦ 8 hex digits ♦/ 

IN char * pszCNonce, /* client nonce */ 

IN char * pszQop, /♦ qop-value: "auth", "auth-int" */ 

IN char ♦ pszHethod, /* method from the request ♦/ 

IN char ♦ pszDigestUrlr /* requested URI* ♦/ 

IN HASHHEX HEntlty, /* H( entity body) if qop-»auth-int- */ 

OUT HASHHEX Response /* request-digest or response-digest */ 
); 

File "digcalcc"; 

f include <global.h> 
I include <md5.h> 
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iinclude <string.h> 
ffinclude "digcalc.h" 

void CvtHext 

IN HASH Bin, . 
OUT HASHHEX Hex 
) 

( 

unsigned short 1; 
unsigned char j; 

for 11 « 0; i < HASHLEN; ( 
j « (Bln(i) » 41 t Oxf; 
if (j <- 9) 

Hex[i*2) - (j + 'OM; 
else 

Hex[l*2J - (j + 'a* - 10); 
j - Bind) 6 Oxf; 
If (1 <- 9) 

Hex(i*2+1) - (j + 'OM; 
else 

Hexti*2+ll » <3 + <a' - 10); 

}; 

Hex (HASHHEXLEN) » •\0»; 

}; 
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/* calculate H{A1) as per spec */ 
void DlgestCalcHAl ( 

IN char * pszAlg, 

IN char * pszUserName, 

IN char * pszRealm, 

IN char * psz Pas sword, 

IN char * pszNonce, 

IN char * pszCNonce, 

OUT HASHHEX SesslonKey 

) 

( 

MD5 CTX MdSCtx; 
HASH HAl; 

M05lnit(CMd5Ctx) ; 

MOSUpdatef&MdSCtx, pszUserName, strlen (pszUserName) ) ; 
MD5Update(SMd5Ctx, 1); 

HD5Update(&Md5Ctx, pszRealm, strlenfpszRealm) ); 
MD5Updato(tMd5Ctx, 1); 

MD5Update(<Md5Ctx, pszPassword, strlenlpszPassword) ) ; 

MDSFlnaKHAl, (MdSCtx); 

If (stricmp(pszAlg, "mdS-sesa" ) 0) { 
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); 



MD5Inlt(fiMd5Ctx); 
MD5Update(£Md5Ctx, HAl, HASHLGN); 
MD5Update(SMd5Ctx, 1); 

MD5Update ( &Hd5Ctx, pszNonce, strlen (pszNonce) ) ; 
MD5Update(fiMd5Ctx, 1); 

MD5Update(&Md5Ctx, pszCNonce, strlen (pszCNonce) ) ; 
MDSrinalfHAl, &Md5Ctx); 

); 

CvtHex(HAl, SesslonKey) ; 



/* calculate request-dlgeat/responae-dlgest as per HTTP Digest spec */ 
void DlgestCalcResponse( 

/* H(A1) */ 

/* nonce from server */ 
/♦ 8 hex digits ♦/ 
/* client nonce */ 

/• qop-value: "auth", "auth-int* */ 
/• method from the request */■ 
/♦ requested URL */ 

/* H(entity body) if qop-^auth-lnt" ♦/ 
/* request-digest or response-digest */ 



i 



IN KASHHCX HAlr 
IN char * pszNonce, 
IN char * pszNonceCount, 
IN char * pszCNonce, 
IN char * pszQop, 
IN char * pszMethod, 
IN char * pszDigestUri, 
IN HASHHEX HEntity, 
OUT HASHHEX Response 



) 



MD5_CTX MdSCtx; 
HASH HA2; 
HASH RespHash; 
HASHHEX HA2Hex; 



// calculate H(A2) 
MD5Init<4Md5Ctx); 

MD5Update(&MdSCtx, pszMethod, strlen (pszMethod) ) ; 
MD5Update(£Md5Ctx, <■:**, 1); 

MD5Update(tMd5Ctx# pazDigestUri, strlen (pszDigestUri )) ; 
if {stricmptpszQop, "auth-lnt") 0) { 

MDSUpdate(4Md5Ctx, 1); 

MD5Update(4MdSCtx, HEntlty, HASHHEXLEN); 

}; 

MDSFinal(HA2, &MdSCtx); 
CvtHex(HA2, HA2Hex); 

// calculate response 
MDSInit{4MdSCtx); 

MDSUpdateCtMdSCtx, HAl, HASHHEXLEN); 
MDSUpdate(tMd5Ctx, 1); 

MOSUpdate(CMdSCtx, pszNonce, strlen (pszNonce) ) ; 
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MDSUpdate ( £Md5Ctx, pszNonceCount, strlen (pszNonceCount ) ) ; 
MD5Update(4Md5Ctx, X); 

MDSUpdate («Md5Ctx, pszCNonce, atrlen(pszCNonce) ) ; 
MDSUpdate (fiMdSCtx, 1); 
MDSUpdate {(MdSCtx, pszQop, strlen (pszQop) ) ; 
MDSUpdate (tMdSCtx, 1); 

»; 

MDSUpdate UMdSCtx, HA2Hex; HASHHEXLEN); 
MDSFlnal (RespHash, AHdSCtx) ; 
CvtHex (RespHash, Response) ; 

); 

File "digtest.c"; 



tlnclude <stdlo.h> 
iinclude "digcalch" 

void maindnt argc, char ** argv) ( 

char ♦ pszNonce - "dcd98b7l02dd2f0e8blld0f600bfb0c093"; 

char * pszCNonce - "Oa4£113b"; 

char * pszUser » "Mufasa"; 

char * pazRealm ■> "test re alm6host.com**; 

char * pszPass « "Circle Of Life"; 

char ♦ pszAlg - "radS"; 

char szNonceCount (9) = "00000001"; 

char * pszMethod « "GET"; 

char ♦ pszQop = "auth*^; 

char * pszURI « "/dir/1 ndex.html"; 

HASHHEX HAl; 

HASHHEX HA2 - ""; 

HASHHEX Response; 

DigestCalcHAl (pszAlg, pszUser, pszRealm, pszPass, pszNonce, 
pszCNonce, HAl); 

DigestCalcRe&pon8e(HAl, pszNonce, szNonceCount, pszCNonce, pszQop, 

pszMethod, pszURI, HA2, Response); 
print f ("Response - %8\n". Response); 

>; 
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Acknowledgement 

Funding for the RFC Editor function is currently provided by the 
Internet Society. 



http:/Avww.ics.uci.edu/pub/ietf/htt|]/rfc26 1 7.bct 



ffc261 7.txt at www.ic3.uci.edu Page 27 of 27 



Franks, et al. Standards Track (Paga 34] 



ht^y/www.ic3.uci.edu/pubi/ietf/htt{Vrfc2617.txt 



9/16/99 



Page 1 of 2 

c 

clickshare 

clickshare service corporation 



Clickshare seeks partners for patent-pending 
micropayments and user-managment technology 

WILLI AMSTOWN, Mass., Oct. 13, 1998 Clickshare Service Corp. is seeking strategic allies, equity 
investors and licensees to assist in the commercialization of its patent-pending Internet subscription, 
microbilling and distributed user- management system. 

"We are aggressively seeking partnerships with one or more technology companies, publishers and 
audience owners such as banks and ISPs to me the Clickshare technology rapidly into the marketplace," 
said said Bill Densmore, president and co-founder of Clickshare. 

A six-month prototype demonstration of the Token Validation Service technology involved nearly 2,000 
users. Marketed as the Clickshare Service, TVS was tested with three publishers: The American 
Reporter, Studio Briefing and The Christian Science Monitor. 

Clickshare is now seeking a patent for TVS. "We believe the service constitutes a novel application of 
technology to the problem of how to make the Internet conunercially viable," said Densmore. 

So far, consumer web publishers have tried to become profitable on advertising alone. Increasingly, they 
are viewing micropayments and personalized information delivery as essential to boosting revenues — 
but few sites have actually ramped up such services. 

"We regard TVS as a vital service because it offers an infrastructure for tagging and identifying 
Internet users for a variety of purposes - as required for Internet information commerce to become 
mainstream," said Densmore. "There are many publishers and equity partners who have looked at what 
we have and may want to play a role in bringing it to market." 

Parties interested in trialing or licensing the TVS technology should contact Clickshare Service Corp. 
[413-458-8001 or corp@clickshare.cQm] to obtain an information packet and arrange for a 
demonstration. 

About the Clickshare Service (TVS) 

Clickshare is a client-server based, distributed user-management system for Internet commerce. It 
enables aggregation of content subscriptions, micropayments, audience measurement by identified user, 
personalization using a "reverse cookie" approach and Web-site access control. Clickshare employs 
"Digital Calling Card (SM)" technology which allows users to view and purchase information at 
multiple, independent web sites using a single ID and password. It enables sale of information "by the 
click" down to 10 cents per item. TVS requires no special end-user software. More information about 
TVS may be found at: http://wvyw. clickshare.cQm/ . "Clickshare" is a registered servicemark of 
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Clickshare Service Corp. 

About Clickshare Service Corp. 

Clickshare Service Corp. [vmw.clickshare.com], was formed in 1997 to acquire technology developed 
by two affiliated companies, Newshare Corp, and Clickshare Corp. The company is researching ways 
for publishers to enter the next century by profitably sharing users and information. The TVS/Clickshare 
technology is the first spinoff of its efforts. Clickshare Service Corp. is privately held and funded and 
has strategic relationships with Massachusetts Ventures Inc. , the A pplied Computing Systems Institute 
of Massachusetts Inc. and the University of Massachusetts Isenberg School of Management. 



Clickshare Service Corp. 
75 Water Street 

Williamstown, MA 01267-0367 USA 
VOICE: (413) 458-8001 
FAX: (413) 458-8002 
EMAIL: corp@clicksharexom 
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Clickshare applauds open market transaction patents as validating 
technologies based on internet diversity 



WILLIAMSTOWN, Mass.. March 4, 1998 - The award of three patents to 
Open Market Inc. is a welcome development because it tends to confer 
credibility on a new class of technologies which leverage the Internet's 
diversity, the president of Clickshare Service Corp. said on Wednesday. 

Clickshare is a development-stage, privately funded technology company 
which owns rights to an Internet distributed user-management system. The 
patent-pending system enables micropayments and other services. The 
full statement by the company's president and co-founder, William P. 
Densmore Jr, appears below. 



"The award on March 3 of the last of three patents to Open Market 
Inc. is a welcome development because it tends to confer credibility 
on a whole class of transaction technologies - those which 
leverage the distributed diversity of the Internet rather than try to 
close it. 



"Corporate technology managers and publishers are confused by 
the claims and features of different vendors. The U.S. Patent and 
Trademark Office examiners, while themselves ovenwhelmed with 
filings, are nonetheless a corps of unbiased technical analysts 
whose only goal is to recognize novel and useful inventions. This 
helps the marketplace to separate valid products from vaporware 
and potential standard-bearers from position seekers. In the 
Internet environment, this may be more valuable to the patent 
holder than license fees or royalties. 

"The Open Market patents, at first blush, do not appear to be so 
broad as to foreclose other approaches to Internet commerce. 
Rather, they signal that in the Wild West environment of the 
Internet, good ideas don*t all come from large corporations. 

"Clickshare's Token Validation Service (TVS), engineered in 1994 
and 1995 and subject of a pending patent application, is a 
compatible and collaborative technology which enables information 
micropayments, personalization, resource access control and 
audience measurement. It vests a user with a Digital Calling Card 
(SM) which can be used for one ID, one password access to 
multiple web sites. It allows consumers to have credit, but remain 
anonymous, and respects privacy by requiring no central names 
database. 

"Most important, TVS allows affiliated publishers and consumer 
billing agents such as ISPs, banks, telcos and retailers to make 
money - by exchanging users and links just as wholesalers and 
retailers help each other execute physical commerce." 
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Editor's Note: Open Market's news release may found at: 

http : //www . openmarket . com/releases/3patents . htm 

Clickshare Service Corp. *s home page is at: 
http : / /www . clickshare . com/ 

SOURCE: Clickshare Service Corp., 477 Congress Street, Portland ME 04101. 
CONTACT: Bill Densmore, (413) 458-8001 / corpeclickshare.com 



Clickshare Service Corp. 

477 Congress Street, Suite 1300 
Portland ME 04101 (USA) 
207-871-7000 
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Building a free market for digital information 



CLICKSHARE/TVS: Q&A 

Q: What is Clickshare Service Corp. offering? 

A: We've developed the patent-pending Token Validation Service (TVS), TVS is not a brand name; the 
brand identity v^ll be created by the licensed operators of Clickshare services. The Clickshare/ TVS 
technology offers six features: 

• AFFILIATION MANAGEMENT It allows audience owners such as publishers, ISPs, telcos, 
banks, portals, affinity groups to manage and profit from the tracking and sharing of their 
respective users and to account for the multi-domain sale of information or products. 

• MICROPAYMENTS ~ It makes it possible for publishers, and information or software owners to 
sell economically and easily to Internet consumers in units as little as 10 cents per item — so called 
micropayments, 

• PERSONALIZATION — It allows consumers "privacy-protected demographics." They can store 
their custom information preferences as part of their user profile and then optionally give those 
preferences to web publishers who wish to personalize their offerings. TVS Digital Calling Card 
(SM) technology makes this possible. 

• ACCESS CONTROL — It permits a web site to differentiate requests for information by 
individual users rather than broad domains even if the user has never registered with that 
particular web site. This "Service Class" technology avoids users having to maintain multiple IDs 
and passwords and allows for universal registration. 

• AUDIENCE MEASUREMENT - Advertisers want the measure the effectiveness of their pitches 
by knowing as much about individual viewers as possible. Basic Internet protocols identify users 
only by "domain." TVS Digital Calling Card technology transfers a unique identifier for each 
user worldwide. This creates a platform for fine-grained demographic analysis while protecting 
user privacy. 

• EASE OF USE The consumer can leverage a smgle billing relationship with a "most-trusted" 
Clickshare Service Provider - such as an ISP, telco, cable company, publisher or other billing 
entity - to purchase information at muhiple web sites with single-ID and password convenience. 
No end-user software is required beyond a standard Web browser. 

Q: What are the overall benefits? 

• UNIVERSAL SETTLEMENT — Publishers and onlline services have begun exploring ways to 
compensate each other for the services they provide to users [Advertising Age, Jan. 20, 1997, 
"Pay per view: Web sites seek deals with ISPs"]. Such contractual relationships will rapidly 
become unmanageable because of the variety of sources of information and users and the need to 



h c c h e c h 



Clickshare Service Corp.: Benefits Q&A 



Page 2 of 4 



have bilateral agreements among players. A single settlement facility, as with the long-distance 
telephone industry, is needed. Also, if users are forced to join information cartels of large 
publishers or user-owners, they will be denied choice and will be forced to accept bundled pricing. 

• UNIVERSAL CREDIT — Many web sites are enrolling users and accepting credit-card payments. 
But each of these relationships works only for that web site, much as a store-credit card issued by 
Sears, doesn't work at Target or Pennys. The experience in the consumer credit industry of a 
gradual conversion of most such accounts to VISA or MasterCard-backed systems demonstrates 
tile desire for consumers and marketers to have less credit facilities rather than more which are 
universal in their application. 

• UNIVERSAL ACCESS — Publishers who seek to charge users on a subscription basis by 
definition exclude the vast majority of potential users who would buy a portion of the web site's 
offerings on a "per-click" basis. TVS, uniquely, offers the opportunity to "have it both ways." Just 
as conventional newspaper and magazine publishers have subscribers and single-copy sales, the 
Clickshare-enabled publisher can have subscribers, but also vend information to visiting 
Clickshare member users "by the click." In the proprietary online world (West, Lexis-Nexis, 
Compuserve, Dialog) this was not been technically feasible because of the lack of a universal 
public network, such as the Internet, that takes care of site access. TVS provides the vicarious 
billing relationship. 

Q: Who's involved in the Clickshare/TVS system? 

• INFORMATION SELLERS - Operators of World Wide Web sites who wish to make money 
fi-om the sale of information or software are called Publishing Members. Examples include: 
newspapers, magazines, specialty publications, new-media entrepreneurs, game vendors and 
software publishers. 

• BILLING AGENTS - Consumers have preexisting, ongoing credit relationships with billing 
agents who agree to become Clickshare Service Providers. In exchange for a negotiated share of 
the "Clickstream" revenue from information sales, these service providers assume responsibility 
for servicing and billing end xisers. Examples include: Internet Service Providers, newspapers, 
specialized publishers, online services, telephone companies, cable and utility companies, credit- 
card issuing banks, retailers and other consumer-credit entities. 

• CUSTOMERS " Internet users who have established an account with a billing agent and who 
seek convenient access to widely distributed digital information are called TVS Members. They 
are customers of their billing agent and need have no direct relationship with Clickshare Service 
Corp, or its licensee/operator. 

• CLICKSHARE SERVICE CORP. - Facilitating the authentication of Member Users, and storing 
records of their access to web sites is the Clickshare Access and Logging Service (CALS). 
Operated by Clickshare Service Corp. or its licensees, CALS is a fault-tolerant network of Internet 
servers which exchange real-time, encoded information with machines operated by information 
sellers and billing agents. 

Q: What is the value of TVS to each of the constituents below? 

INFORMATION SELLERS 
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• A way to get guaranteed payment for selling information on the Internet 

• A third revenue stream after advertising and subscriptions 

• A digital equivalent of "single-copy sales" to casual web-site visitors. 

• A way to obtain anonymous user demographic and preference infomation v^thout requiring 
registration. 

• Enhances customer service through ability to personalize 

• Enables site access by service class such as subscriber only 

• Produces auditabie, third-party "page-view" data for advertisers 

• Low entry barrier, pay-as-you-profit cost structure 

BILLING AGENTS ("Clickshare Service Providers") 

• A new revenue stream - selling iitformation instead of just Internet connectivity or physical goods 

• Greater user "stickiness" by providing added value of access to multi-site resources and 
information with single-bill and registration simplicity. 

• Low entry barrier, pay-as-you-profit cost structure 

• Leverage existing billing facility for profits at little incremental cost 

• Provides credibility and co-marketing strength of an affiliate relationship 

• Become a source of anonymous but user-specific market data on where customers are going for 
information and services 

• Solidifies billing agent as "home port" for customer 

CUSTOMER 

• Convenience of single ID and password and one-stop registration for information and product 
access anywhere on Web which is Clickshare enabled 

• Privacy-protected demographics are never accompanied by name, address or credit information 
when submitted to affiliated sites. 

• Choice of billing agents (one or many) 

• Ease of payment through single, periodic bill via existing credit facilities 

• Requires no special end-user software and no new end-user credit relationship 

• Instant point-and-click purchasing with authentication in background 

• No transfer of credit-card mformation across the Internet 

• Total control of who can use personal information 

• User's address optionally protected from unwanted mail 

• Parental control built and regulated by publisher not by government 

• Nightly advisory of information purchases 

CLICKSHARE SERVICE CORP. (or licensee/partner) 

• Front-loaded revenues fi-om CPM and CSP member enrollment fees 

• Cost-based revenues fi*om per-enabled-user fees 

• Scaled, annuity revenue fi-om per-click transaction fees 

• Service fees for audience measurement data, installation and support 

• Commissions on advertising sales (Adshare — pay-per-vie\y ads) 

Q: Is Clickshare available now? 



Trials of C lickshare are anticipated to occur early in 1999. A prototype demonstration is available at 
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http://1999xlicksharexom/trvit/ Potential service providers and content providers should contact 
Clickshare Service Corp. to arrange to participate in trials. 

BACK TO TOP OF PAGE 

BACK TO HOME PAGE 



Clickshare is a U.S.-registered servicemark of Clickshare Service Corp. 
Copyright. J 999. Clickshare Service Corp. All rights reserved 



Clickshare Service Corporation 

75 Water St, 

Williamstown. MA 01267-0367 USA 
VOICE: (413) 458-8001 
FAX: (413) 458-8002 
EMAIL: corpC^clicksharccom 
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Web • Images • Groups - Directory- News • 
Searched the web for token validation service. 



Results 1 - 10 of about 34,300. Search took 0.13 seconds. 



W3C HTML Validation Service Results 

... Error an attribute specification must start with a name or name token. ... your document, 
you should also check it for validity using the W3C CSS Validation Service .... 
www.balancedscorecard.org/bscit/validations/ v2001/Sandia_401T.htm - 53k - Cached - Similar pages 

W3C HTML Validation Service Results 

HTML Validation Service Results. Document Checked. ... 23/96> ^ Error: 

value of attribute "NAME" must be a single token. Line 7, column ... 

www.balancedscorecard.org/bscit/ validations/v2000/NBL.htm - 30k - Cached - Similar pages 
[ More results from www.balancedscorecard.org 1 

About the Validation Service 

... Syntax Errors. The en-or messages returned by the validation service can 
appear obscure. ... Name Token Ignored and Incorrect Character in Markup. ... 
www.cf.ac.uk/Tools/check-html/help-notes.html - 6k - Cached - Similar pages 

Error Explanations for The W3C MarkUo V alidation Service 
W3C Markup Validation Service. ... A special case of the previous error; the attribute 
in question is defined to take as value an SGML name token, which must begin ... 
validator.w3.org/docs/errors.html - 44k - Cached - Similar pages 

W3C HTML Validation Service Results 

... one or more options that alter the content of the document before validation, or 
have „. Error an attribute specification must start with a name or name token. ... 

spazioinwind.libero.it/gianluca_affinito/ web_barriere/report/inail/inail_w3.htm - 23k - Cached - Similar pages 



Error Explanations for The W3C HTML Validation Service 
W3C HTML Validation Service (UWA CWIS ... A special case of the previous error; the attribute 
in question is defined to take as value an SGML name token, which must ... 
validatorcwis.uwa.edu.au/docs/errors.html - 35k - Cached - Similar pages 

W3C HTML Validation Service Results 

... Error: value of attribute "name" must be a single token. ... you use CSS in your document, 
you should also check it for validity using the W3C CSS Validation Service ... 

kensall.com/gov/xhtml/validation/tidy-check.html - 38k - Cached - Similar pages 

[Pon Pistributed File Authorization Service 
File Format: PDF/Adobe Acrobat - View as HTML 

... You may use a key sen/er for validating an authorization token. ... Such validation would 
be necessary if a beacon wants to provide service only to certain ... 
www.cse.nd.edu/-surendar/teach/spr02/ubicomp/hw03.pdf - Similar pages 
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SPECIAL PUBLISHING MEMBER RATES 

... Registration as a Newshare Publishing Member within the Newshare Token Validation 
Service (TVS) (effective mid-1995), enabling the receipt of royalty ... 

www.newshare.com/Newshare/Members/ Publishing/MAR95PubRates.html - 9k - Cached - Similar pages 
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File Formal: PDF/Adobe Acrobat - View as HTML 

.„ tokens and PIN letters to the End User 5. WlSeKey eComercePKt CA Certificate Authority 
Validation Service Directory Service Certificate, token/smart card ... 

www.itu.int/ITU-D/e-strategy/ecdc/Senninars/ MoscowCIS/Presentations/wisekey 1 .pdf - Similar pages 
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